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

2017-06-20 Thread Bernd Eckenfels (JIRA) 

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

Bernd Eckenfels resolved DAEMON-361.

Resolution: Invalid
  Assignee: Bernd Eckenfels

Tomcat implements its own service methods in the Bootstrap class without the 
Apache Commons Daemon classes, so getting help and potentially opening a bug 
report should happen there: http://tomcat.apache.org/bugreport.html

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



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

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

2017-06-20 Thread Raghavaraju Kudari (JIRA) 

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

Raghavaraju Kudari commented on DAEMON-361:
---

Hi Bernd,

Thanks for the response. 
But issue is not with WinRun4J. I just specified that to explain the issue, 
which we are facing. We are using "catalina.jar" startup API which resides in 
tomcat application, to start and stop tomcat server . The issue is very much 
similar to  DAEMON-298. If this is wrong place to create this ticket, please 
let us know where we can place this issue?


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



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

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

2017-06-20 Thread Bernd Eckenfels (JIRA) 

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

Bernd Eckenfels commented on DAEMON-361:


{quote}To create windows service entry we used WinRun4J API 
{quote}
How is that related to Apache Commons Daemon?`It looks like it is not using any 
Apache classes 
https://github.com/poidasmith/winrun4j/search?utf8=%E2%9C%93=apache=

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



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

[jira] [Commented] (POOL-327) GKOP: returnObject does not unblock threads waiting in borrowObject if maxIdle=0

2017-06-20 Thread Phil Steitz (JIRA) 

[ 
https://issues.apache.org/jira/browse/POOL-327?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=1605#comment-1605
 ] 

Phil Steitz commented on POOL-327:
--

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] [Created] (COMPRESS-413) Travis build redundantly repeats compilation and tests redundantly

2017-06-20 Thread Simon Spero (JIRA) 
Simon Spero created COMPRESS-413:


 Summary: Travis build redundantly repeats compilation and tests 
redundantly
 Key: COMPRESS-413
 URL: https://issues.apache.org/jira/browse/COMPRESS-413
 Project: Commons Compress
  Issue Type: Improvement
  Components: Build
Affects Versions: 1.14
 Environment: Travis
Reporter: Simon Spero
Priority: Minor
 Fix For: 1.15


The Travis build setup is suboptimal.

At the moment, code is compiled and installed by the default install phase.  
Then the default build phase is executed, which compiles and runs the tests.
If the tests succeed, then the build is cleaned, recompiled, and retested; this 
time with 
coverage enabled. 

The .travis.yml file could be changed to skip the install phase, and to run 
tests with coverage during the build phase. 
The coveralls plugin can be configured in the pom  to not fail the build if the 
service is unreachable, so forks that don't have jacoco enabled won't always 
have their builds fail. 

Also, the jdk switching in the trusty container seems to be not working 
properly at the moment, so installing a jdk7 doesn't work properly.

These changes evolved as I was poking jenkins last night.



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

[jira] [Commented] (COMPRESS-281) Archives don't contain resource fork on Macs

2017-06-20 Thread Simon Spero (JIRA) 

[ 
https://issues.apache.org/jira/browse/COMPRESS-281?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16056488#comment-16056488
 ] 

Simon Spero commented on COMPRESS-281:
--

Things changed so that now this info is stored as an xattr, with the legacy 
"..namedfork/rsrc" being just another attribute.  Before,  extended attributes 
were stored as a special fork. 

In 
{{#define XATTR_RESOURCEFORK_NAME   "com.apple.ResourceFork"}}

The MacOS  release of openjdk doesn't an extended attribute (UserDefined) file 
view.  An implementation would be quite similar to the Linux version; however, 
no-one has added it since JDK 7 came out;  support isn't included in JDK-9 
either.  You could implement the required code, and write a shim around default 
FileSystemProvider to do the extra attribute wrangling. 

The default provider can be replaced using the mechanism discussed in 
[FileSystems::getDefault | 
https://docs.oracle.com/javase/7/docs/api/java/nio/file/FileSystems.html#getDefault()],
 which requires setting a system property.  This probably has to be done on the 
command line, since by the time any user code is executed the default file 
system will probably have been instantiated.  Note that the value of the 
property can be a list of classes;  these will be instantiated in the order in 
which they are given.   Each instance will be passed as an argument to the 
next, with the first class being passed an instance of the system default 
classloader;  the final class will become the actual default.  

The wrapper implementation  delegate most methods to the passed in provider. 
The obvious places where changes are needed
are in the attribute related methods.  The wrapper also needs to create a 
mostly delegating instance of FileSystem, with changes to return the right 
provider and add "user" to the list of supported file views. 

 It probably also needs to provide an implementation of 
UserDefinedFileAttributeView, and some native code to invoke the appropriate 
system call.

The Linux implementation, which needs a few  extra system call wrappers in its 
Dispatcher:
 
[LinuxUserDefinedFileAttributeView.java|http://hg.openjdk.java.net/jdk8u/jdk8u/jdk/file/e03f9868f7df/src/solaris/classes/sun/nio/fs/LinuxUserDefinedFileAttributeView.java]
 which relies on a few NIO methods in 
 [LinuxNativeDispatcher.c| 
http://hg.openjdk.java.net/jdk8u/jdk8u/jdk/file/e03f9868f7df/src/solaris/native/sun/nio/fs/LinuxNativeDispatcher.c#l83
 ] 

Or the Solaris implementation, which uses a solaris-specific flag  - the jdk 8 
sources are a little solaris biased, as you may have spotted from the url path. 

[SolarisUserDefineFileAttributeView.java|http://hg.openjdk.java.net/jdk8u/jdk8u/jdk/file/e03f9868f7df/src/solaris/classes/sun/nio/fs/SolarisUserDefinedFileAttributeView.java]

This is probably a bit out of scope. 


An alternative disgustingly hacky approach would be to use /usr/bin/xattr, 
which can make the system calls, and can read/dump the contents of an attribute 
in hex. Did I mention that /usr/bin/xattr is a python script?  Feel the 
performance flow through you.

> Archives don't contain resource fork on Macs
> 
>
> Key: COMPRESS-281
> URL: https://issues.apache.org/jira/browse/COMPRESS-281
> Project: Commons Compress
>  Issue Type: Wish
>Reporter: Dimple Rohara
>Priority: Critical
>
> Currently, we are able to create archive on windows. But for Mac,it doesn't 
> save the resource fork information. I wish there was more compatibility among 
> the archives created on different Operating systems and could be used easily 
> cross-platform.



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

[jira] [Commented] (COMPRESS-410) Remove ZipEncoding implementations introduced to work around problems in jdk 1.4

2017-06-20 Thread ASF GitHub Bot (JIRA) 

[ 
https://issues.apache.org/jira/browse/COMPRESS-410?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16056347#comment-16056347
 ] 

ASF GitHub Bot commented on COMPRESS-410:
-

Github user sesuncedu closed the pull request at:

https://github.com/apache/commons-compress/pull/36


> Remove   ZipEncoding implementations introduced to work around problems in 
> jdk 1.4
> --
>
> Key: COMPRESS-410
> URL: https://issues.apache.org/jira/browse/COMPRESS-410
> Project: Commons Compress
>  Issue Type: Improvement
>  Components: Archivers
>Affects Versions: 1.14
>Reporter: Simon Spero
>Priority: Minor
>
> There are several implementations of ZipEncoding that are provided to work 
> around missing character sets  in JDK 1.4. 
> Since commons-compress requires JDK7 or later, this code is no longer needed. 
> As the classes are package private, they can be removed without affecting the 
> API. 



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

[jira] [Commented] (COMPRESS-410) Remove ZipEncoding implementations introduced to work around problems in jdk 1.4

2017-06-20 Thread ASF GitHub Bot (JIRA) 

[ 
https://issues.apache.org/jira/browse/COMPRESS-410?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16056344#comment-16056344
 ] 

ASF GitHub Bot commented on COMPRESS-410:
-

GitHub user sesuncedu reopened a pull request:

https://github.com/apache/commons-compress/pull/36

COMPRESS-410 Remove Non-NIO character set encoders.

As a special case, the UTF-8 encoder will replace malformed / unmappable 
input with '?'.
This behavior is required for compatibility with existing behavior.

Signed-off-by: Simon Spero 

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

$ git pull https://github.com/sesuncedu/commons-compress COMPRESS-410

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

https://github.com/apache/commons-compress/pull/36.patch

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

This closes #36


commit 1c9e1d8218ccd102567273eebdfba187ca545fc8
Author: Simon Spero 
Date:   2017-06-17T00:17:13Z

COMPRESS-410 Remove Non-NIO character set encoders.
As a special case, the UTF-8 encoder will replace malformed / unmappable 
input with '?'.
This behavior is required for compatibility with existing behavior.

Signed-off-by: Simon Spero 

commit 7fdfde85a8ab19c1f47efe4d3a9d0bad653182b2
Author: Simon Spero 
Date:   2017-06-17T16:45:44Z

javadoc for HasCharset

Signed-off-by: Simon Spero 

commit 651eae5399ba5b980257703b0ff98d7f7d89aee3
Author: Simon Spero 
Date:   2017-06-18T22:55:38Z

Do better estimating of required buffer size for character encoding.  If an 
unencodable character is found that requires output buffer expansion,  scan 
buffer for all such characters, and attempt to expand buffer only once.

Signed-off-by: Simon Spero 

commit c9dfc31dbbbe099927a843197936b19e41f64d5c
Author: Simon Spero 
Date:   2017-06-11T22:48:42Z

COMPRESS-407 Validate Block and Record Sizes

Require block size >=0 that is multiple of 512 bytes.
Use block size of 512 if one is not given.
Require record size of 512 bytes. Deprecate constructors taking recordSize 
as parameter

Modify tests to check for enforcement of record size == 512
Modify tests to check for correct overall length  for
different block sizes including PAX default, USTAR default, and unspecified.

Signed-off-by: Simon Spero 

commit 15764594371bd8792b28d6cb415b9fcf1a9a60c2
Author: Michael Hausegger 
Date:   2017-06-13T21:47:50Z

add-some-Unit-Tests Added some Unit Tests to increase code coverage.

commit 9d81c8fcad4cbedcbe0cfd81a7af492800d1f726
Author: Simon Spero 
Date:   2017-06-15T18:27:48Z

Redoing more buffer stuff

Signed-off-by: Simon Spero 

commit 40736df64b5360f3ea3ad481ed81b47bd6650b30
Author: Simon Spero 
Date:   2017-06-15T18:27:48Z

Redoing more buffer stuff

Signed-off-by: Simon Spero 

commit ead6bc6db225d8da124e37d67ecd081e3167d0ca
Author: Simon Spero 
Date:   2017-06-15T23:26:12Z

More ByteBuffer methods for TarUtils

Signed-off-by: Simon Spero 

commit ab95c59eabdd283ec993bab7559b14864c1bcc57
Author: Simon Spero 
Date:   2017-06-16T20:24:12Z

More ByteBuffer methods for TarUtils

Signed-off-by: Simon Spero 

commit a5db19a7ff84114033d3e8411e1a02497e0c1bd8
Author: Michael Hausegger 
Date:   2017-06-16T18:12:20Z

add-some-Unit-Tests Removed @author tags in comments.

commit 028b81cf85547edc7c54b6ab8c4395ac8c931c20
Author: Michael Hausegger 
Date:   2017-06-16T18:22:10Z

add-some-Unit-Tests Removed test testGetValueThrowsNullPointerException in 
class ChecksumCalculatingInputStreamTest. Test represented a bug/defect which 
is going to be fixed in a different branch.

commit 3908b334156c8f5a44ac3777d73adb80f0f973d2
Author: Michael Hausegger 
Date:   2017-06-16T18:38:00Z

add-some-Unit-Tests Minor variable renaming.

commit e5c2cce4f9b7f3aca848b3c608c77f5c7911a662
Author: Michael Hausegger 
Date:   2017-06-16T18:44:40Z

add-some-Unit-Tests Added myself as contributor to pom.xml as "requested" 
by Stefan Bodewig.

commit 04109a4d0924b7a79319e2ce382bc9fedea51a65
Author: Michael Hausegger 
Date:   2017-06-16T20:16:06Z

add-some-Unit-Tests Added additional Unit Tests.

commit d7195a8bc61d151227540521b723ca580bd26dab
Author: Simon Spero

[jira] [Commented] (COMPRESS-410) Remove ZipEncoding implementations introduced to work around problems in jdk 1.4

2017-06-20 Thread ASF GitHub Bot (JIRA) 

[ 
https://issues.apache.org/jira/browse/COMPRESS-410?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16056343#comment-16056343
 ] 

ASF GitHub Bot commented on COMPRESS-410:
-

Github user sesuncedu commented on the issue:

https://github.com/apache/commons-compress/pull/36
  
reopening just to see if I didn't need to create a new branch and cherry 
pick


> Remove   ZipEncoding implementations introduced to work around problems in 
> jdk 1.4
> --
>
> Key: COMPRESS-410
> URL: https://issues.apache.org/jira/browse/COMPRESS-410
> Project: Commons Compress
>  Issue Type: Improvement
>  Components: Archivers
>Affects Versions: 1.14
>Reporter: Simon Spero
>Priority: Minor
>
> There are several implementations of ZipEncoding that are provided to work 
> around missing character sets  in JDK 1.4. 
> Since commons-compress requires JDK7 or later, this code is no longer needed. 
> As the classes are package private, they can be removed without affecting the 
> API. 



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

[jira] [Commented] (COMPRESS-410) Remove ZipEncoding implementations introduced to work around problems in jdk 1.4

2017-06-20 Thread ASF GitHub Bot (JIRA) 

[ 
https://issues.apache.org/jira/browse/COMPRESS-410?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16056335#comment-16056335
 ] 

ASF GitHub Bot commented on COMPRESS-410:
-

Github user coveralls commented on the issue:

https://github.com/apache/commons-compress/pull/37
  

[![Coverage 
Status](https://:/builds/12055314/badge)](https://:/builds/12055314)

Coverage increased (+0.04%) to 84.77% when pulling 
**922051d1f2250256697a1b042f1f319b2950fc45 on sesuncedu:COMPRESS-410-REDUX** 
into **4be9979b45ceadc50dc24607884d34613fead1f5 on apache:master**.



> Remove   ZipEncoding implementations introduced to work around problems in 
> jdk 1.4
> --
>
> Key: COMPRESS-410
> URL: https://issues.apache.org/jira/browse/COMPRESS-410
> Project: Commons Compress
>  Issue Type: Improvement
>  Components: Archivers
>Affects Versions: 1.14
>Reporter: Simon Spero
>Priority: Minor
>
> There are several implementations of ZipEncoding that are provided to work 
> around missing character sets  in JDK 1.4. 
> Since commons-compress requires JDK7 or later, this code is no longer needed. 
> As the classes are package private, they can be removed without affecting the 
> API. 



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

[jira] [Commented] (COMPRESS-410) Remove ZipEncoding implementations introduced to work around problems in jdk 1.4

2017-06-20 Thread ASF GitHub Bot (JIRA) 

[ 
https://issues.apache.org/jira/browse/COMPRESS-410?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16056330#comment-16056330
 ] 

ASF GitHub Bot commented on COMPRESS-410:
-

GitHub user sesuncedu reopened a pull request:

https://github.com/apache/commons-compress/pull/37

COMPRESS-410 - cherry picked  to fix merging issues

Remove non-NIO character set encoders. 

Fixes rebasing related issues in previous PR 


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

$ git pull https://github.com/sesuncedu/commons-compress COMPRESS-410-REDUX

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

https://github.com/apache/commons-compress/pull/37.patch

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

This closes #37


commit 5a7ecf1a52d078cf005082c22d302ee9dcc2faf0
Author: Simon Spero 
Date:   2017-06-17T00:17:13Z

COMPRESS-410 Remove Non-NIO character set encoders.
As a special case, the UTF-8 encoder will replace malformed / unmappable 
input with '?'.
This behavior is required for compatibility with existing behavior.

Signed-off-by: Simon Spero 

(cherry picked from commit 0d41ac4)
Signed-off-by: Simon Spero 

commit 8125dccb36792fdcc83c7359d13ecade39852562
Author: Simon Spero 
Date:   2017-06-17T16:45:44Z

javadoc for HasCharset

Signed-off-by: Simon Spero 

(cherry picked from commit b70c7c2)
Signed-off-by: Simon Spero 

commit cf3fa1ecd677b0d405e6018b91aa13f90ecb3b7c
Author: Simon Spero 
Date:   2017-06-17T00:17:13Z

COMPRESS-410 Remove Non-NIO character set encoders.
As a special case, the UTF-8 encoder will replace malformed / unmappable 
input with '?'.
This behavior is required for compatibility with existing behavior.

Signed-off-by: Simon Spero 

(cherry picked from commit 1987719)
Signed-off-by: Simon Spero 

commit fb52100291ed3f69581f6a6dc5062a07e6d52ae8
Author: Simon Spero 
Date:   2017-06-18T22:55:38Z

Do better estimating of required buffer size for character encoding.  If an 
unencodable character is found that requires output buffer expansion,  scan 
buffer for all such characters, and attempt to expand buffer only once.

Signed-off-by: Simon Spero 

(cherry picked from commit aa30e21)
Signed-off-by: Simon Spero 

commit 9f76e86f71d36897895e1e5f49b522d12602f3cc
Author: Simon Spero 
Date:   2017-06-15T18:27:48Z

Redoing more buffer stuff

Signed-off-by: Simon Spero 

(cherry picked from commit 330c8b3)
Signed-off-by: Simon Spero 

commit b92044a5fe95a8b6901040ee8b4c698c0a650e7d
Author: Simon Spero 
Date:   2017-06-18T23:27:42Z

Test that ebcidic encoding is supported (making sure "%U" replacement 
strings don't use ascii encodings)

Signed-off-by: Simon Spero 

(cherry picked from commit f1ec715)
Signed-off-by: Simon Spero 

commit ae1e7b07f0e9483c07d33cf49862660cca3da81e
Author: Simon Spero 
Date:   2017-06-19T00:04:35Z

Add licence comment to HasCharset

Signed-off-by: Simon Spero 

commit 7e01241512f3f4059fa8d909bf7f98379ef4f373
Author: Simon Spero 
Date:   2017-06-19T00:10:46Z

Resurrected HasCharset in the wrong place (not beyond the grave).

Signed-off-by: Simon Spero 

commit 922051d1f2250256697a1b042f1f319b2950fc45
Author: Simon Spero 
Date:   2017-06-19T10:07:02Z

Remove methods and change test + throw to assert to please the coveralls

Signed-off-by: Simon Spero 




> Remove   ZipEncoding implementations introduced to work around problems in 
> jdk 1.4
> --
>
> Key: COMPRESS-410
> URL: https://issues.apache.org/jira/browse/COMPRESS-410
> Project: Commons Compress
>  Issue Type: Improvement
>  Components: Archivers
>Affects Versions: 1.14
>Reporter: Simon Spero
>Priority: Minor
>
> There are several implementations of ZipEncoding that are provided to work 
> around missing character sets  in JDK 1.4. 
> Since commons-compress requires JDK7 or later, this code is no longer needed. 
> As the classes are package private, they can be removed without affecting the 
> API. 



--
This message was sent by

[jira] [Commented] (COMPRESS-410) Remove ZipEncoding implementations introduced to work around problems in jdk 1.4

2017-06-20 Thread ASF GitHub Bot (JIRA) 

[ 
https://issues.apache.org/jira/browse/COMPRESS-410?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16056329#comment-16056329
 ] 

ASF GitHub Bot commented on COMPRESS-410:
-

Github user sesuncedu closed the pull request at:

https://github.com/apache/commons-compress/pull/37


> Remove   ZipEncoding implementations introduced to work around problems in 
> jdk 1.4
> --
>
> Key: COMPRESS-410
> URL: https://issues.apache.org/jira/browse/COMPRESS-410
> Project: Commons Compress
>  Issue Type: Improvement
>  Components: Archivers
>Affects Versions: 1.14
>Reporter: Simon Spero
>Priority: Minor
>
> There are several implementations of ZipEncoding that are provided to work 
> around missing character sets  in JDK 1.4. 
> Since commons-compress requires JDK7 or later, this code is no longer needed. 
> As the classes are package private, they can be removed without affecting the 
> API. 



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

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

2017-06-20 Thread Raghavaraju Kudari (JIRA) 

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

Raghavaraju Kudari updated DAEMON-361:
--
Comment: was deleted

(was: Looking like this is similar issue.)

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



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

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

2017-06-20 Thread Raghavaraju Kudari (JIRA) 

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

Raghavaraju Kudari updated DAEMON-361:
--
Comment: was deleted

(was: Looking like this is similar issue)

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



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

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

2017-06-20 Thread Raghavaraju Kudari (JIRA) 

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

Raghavaraju Kudari edited comment on DAEMON-361 at 6/20/17 1:17 PM:


[^error.png]


was (Author: raghavaraju.k):
The error we are facing when tried to stop the server

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



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

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

2017-06-20 Thread Raghavaraju Kudari (JIRA) 

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

Raghavaraju Kudari commented on DAEMON-361:
---

Looking like this is similar issue.

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



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

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

2017-06-20 Thread Raghavaraju Kudari (JIRA) 

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

Raghavaraju Kudari commented on DAEMON-361:
---

Looking like this is similar issue

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



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

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

2017-06-20 Thread Raghavaraju Kudari (JIRA) 

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

Raghavaraju Kudari updated DAEMON-361:
--
Attachment: error.png

The error we are facing when tried to stop the server

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



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

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

2017-06-20 Thread Raghavaraju Kudari (JIRA) 
Raghavaraju Kudari created DAEMON-361:
-

 Summary: Windows service fails to stop with error code 1053 (using 
Windows service manager)
 Key: DAEMON-361
 URL: https://issues.apache.org/jira/browse/DAEMON-361
 Project: Commons Daemon
  Issue Type: Bug
 Environment: windows 7/8/10
Reporter: Raghavaraju Kudari


We are using windows service to start and stop our application.
It is starting but not stopping and giving "{color:red}Error 1053 : "The 
service did not respond to start or control request in a timely fashion{color}" 

To create windows service entry we used WinRun4J API and using catalina.jar 
startup classes
(org.apache.catalina.startup.Bootstrap) to perform this operation.

It was worked earlier when we used tomcat 7 and started facing the issue after 
we upgraded to tomcat 8.5



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

[jira] [Created] (JEXL-227) JexlScriptEngineFactory.getEngineVersion() should return actual version, ie 3.1 as of reporting

2017-06-20 Thread Dmitri Blinov (JIRA) 
Dmitri Blinov created JEXL-227:
--

 Summary: 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] [Comment Edited] (NET-408) problem connecting to ProFTPD with FTPES

2017-06-20 Thread Jouko Toivonoja (JIRA) 

[ 
https://issues.apache.org/jira/browse/NET-408?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16055584#comment-16055584
 ] 

Jouko Toivonoja edited comment on NET-408 at 6/20/17 11:07 AM:
---

Erick Lichtas, I have tried your fix but I'm facing this:
450 TLS session of data connection has not resumed or the session does not 
match the control connection

Any ideas why is this happening?

Pretty sure that the server is FileZilla, but unfortunately I have no control 
over it.


SSL-debug:

{code:java}
***
pool-20-thread-1, WRITE: TLSv1.2 Handshake, length = 80
DefaultQuartzScheduler_Worker-10, called closeInbound()
DefaultQuartzScheduler_Worker-10, fatal error: 80: Inbound closed before 
receiving peer's close_notify: possible truncation attack?
javax.net.ssl.SSLException: Inbound closed before receiving peer's 
close_notify: possible truncation attack?
%% Invalidated:  [Session-7, TLS_ECDHE_RSA_WITH_AES_128_CBC_SHA256]
DefaultQuartzScheduler_Worker-10, SEND TLSv1.2 ALERT:  fatal, description = 
internal_error
DefaultQuartzScheduler_Worker-10, WRITE: TLSv1.2 Alert, length = 64
This engine was forced to close inbound, without having received the proper 
SSL/TLS close notification message from the peer, due to end of stream.
DefaultQuartzScheduler_Worker-10, called closeOutbound()
DefaultQuartzScheduler_Worker-10, closeOutboundInternal()
DefaultQuartzScheduler_Worker-10, called closeOutbound()
DefaultQuartzScheduler_Worker-10, closeOutboundInternal()
DefaultQuartzScheduler_Worker-10, WRITE: TLSv1.2 Application Data, length = 6
DefaultQuartzScheduler_Worker-10, called closeOutbound()
DefaultQuartzScheduler_Worker-10, closeOutboundInternal()
DefaultQuartzScheduler_Worker-10, SEND TLSv1.2 ALERT:  warning, description = 
close_notify
DefaultQuartzScheduler_Worker-10, WRITE: TLSv1.2 Alert, length = 64
DefaultQuartzScheduler_Worker-10, called closeInbound()
DefaultQuartzScheduler_Worker-10, fatal error: 80: Inbound closed before 
receiving peer's close_notify: possible truncation attack?
javax.net.ssl.SSLException: Inbound closed before receiving peer's 
close_notify: possible truncation attack?
%% Invalidated:  [Session-6, TLS_ECDHE_RSA_WITH_AES_128_CBC_SHA256]
DefaultQuartzScheduler_Worker-10, SEND TLSv1.2 ALERT:  fatal, description = 
internal_error
DefaultQuartzScheduler_Worker-10, Exception sending alert: java.io.IOException: 
writer side was already closed.
This engine was forced to close inbound, without having received the proper 
SSL/TLS close notification message from the peer, due to end of stream.
{code}



was (Author: jtoivonoja):
Erick Lichtas, I have tried your fix but I'm facing this:
450 TLS session of data connection has not resumed or the session does not 
match the control connection

Any ideas why is this happening?

Pretty sure that the server is FileZilla, but unfortunately I have no control 
over it.

> problem connecting to ProFTPD with FTPES
> 
>
> Key: NET-408
> URL: https://issues.apache.org/jira/browse/NET-408
> Project: Commons Net
>  Issue Type: Bug
>  Components: FTP
>Affects Versions: 2.2, 3.0
> Environment: ProFTPD 1.3.3d on SUSE Linux Enterprise Server 10.1 
> 32bit, Kernel 2.6.16.46-0.12-default (config file attached)
> ProFTPD 1.3.3d on OpenSUSE 64bit Linux 2.6.34.8-0.2-desktop
> Java 1.5
>Reporter: Michael Voigt
> Attachments: BCFTPSClient.java, ftpes.jpg, 
> FTPSClientWithTLSResumption.zip, proftpd.conf, PTFTPSClient.java
>
>
> I have a problem with the FTPClient connecting to a ProFTPD server.
> If the server uses the configuration option "TLSProtocol TLSv1", I
> cannot connect to it at all. I recieve the following error message:
> - javax.net.ssl.SSLException: Unrecognized SSL message, plaintext connection
> On the server side I see in the log:
> unable to accept TLS connection: protocol error:
> -  (1) error:14094416:SSL routines:SSL3_READ_BYTES:sslv3 alert
> certificate unknown
> - TLS/TLS-C negotiation failed on control channel
> If the server uses the configuration option "TLSProtocol SSLv23", I
> can connect to it but I cant transfer any files. In the server log I
> see:
> - starting TLS negotiation on data connection
> - TLSv1/SSLv3 renegotiation accepted, using cipher RC4-MD5 (128 bits)
> - client did not reuse SSL session, rejecting data connection (see
> TLSOption NoSessionReuseRequired)
> - unable to open data connection: TLS negotiation failed
> If I add the NoSessionReuseRequired parameter to the ProFTPD config
> everything works fine.
> Here is my code:
>FTPClient ftpClient = new FTPClient();
>ftpClient = new FTPSClient("TLS");
>// this throws an exception with TLSProtocol TLSv1
>ftpClient.connect(host, port);
>int reply = ftpClient.getReplyCode();
>

[jira] [Commented] (NET-408) problem connecting to ProFTPD with FTPES

2017-06-20 Thread Jouko Toivonoja (JIRA) 

[ 
https://issues.apache.org/jira/browse/NET-408?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16055584#comment-16055584
 ] 

Jouko Toivonoja commented on NET-408:
-

Erick Lichtas, I have tried your fix but I'm facing this:
450 TLS session of data connection has not resumed or the session does not 
match the control connection

Any ideas why is this happening?

Pretty sure that the server is FileZilla, but unfortunately I have no control 
over it.

> problem connecting to ProFTPD with FTPES
> 
>
> Key: NET-408
> URL: https://issues.apache.org/jira/browse/NET-408
> Project: Commons Net
>  Issue Type: Bug
>  Components: FTP
>Affects Versions: 2.2, 3.0
> Environment: ProFTPD 1.3.3d on SUSE Linux Enterprise Server 10.1 
> 32bit, Kernel 2.6.16.46-0.12-default (config file attached)
> ProFTPD 1.3.3d on OpenSUSE 64bit Linux 2.6.34.8-0.2-desktop
> Java 1.5
>Reporter: Michael Voigt
> Attachments: BCFTPSClient.java, ftpes.jpg, 
> FTPSClientWithTLSResumption.zip, proftpd.conf, PTFTPSClient.java
>
>
> I have a problem with the FTPClient connecting to a ProFTPD server.
> If the server uses the configuration option "TLSProtocol TLSv1", I
> cannot connect to it at all. I recieve the following error message:
> - javax.net.ssl.SSLException: Unrecognized SSL message, plaintext connection
> On the server side I see in the log:
> unable to accept TLS connection: protocol error:
> -  (1) error:14094416:SSL routines:SSL3_READ_BYTES:sslv3 alert
> certificate unknown
> - TLS/TLS-C negotiation failed on control channel
> If the server uses the configuration option "TLSProtocol SSLv23", I
> can connect to it but I cant transfer any files. In the server log I
> see:
> - starting TLS negotiation on data connection
> - TLSv1/SSLv3 renegotiation accepted, using cipher RC4-MD5 (128 bits)
> - client did not reuse SSL session, rejecting data connection (see
> TLSOption NoSessionReuseRequired)
> - unable to open data connection: TLS negotiation failed
> If I add the NoSessionReuseRequired parameter to the ProFTPD config
> everything works fine.
> Here is my code:
>FTPClient ftpClient = new FTPClient();
>ftpClient = new FTPSClient("TLS");
>// this throws an exception with TLSProtocol TLSv1
>ftpClient.connect(host, port);
>int reply = ftpClient.getReplyCode();
>if (!FTPReply.isPositiveCompletion(reply)) {
>ftpClient.disconnect();
>log.error("The FTP Server did not return a positive 
> completion reply!");
>throw new 
> FtpTransferException(ECCUtils.ERROR_FTP_CONNECTION);
>}
>boolean loginSuccessful = ftpClient.login(userName, password);
>if (!loginSuccessful) {
>log.error("Login to the FTP Server failed! The 
> credentials are not valid.");
>throw new 
> FtpTransferException(ECCUtils.ERROR_FTP_LOGIN);
>}
>ftpClient.execPBSZ(0);
>ftpClient.execPROT("P");
>boolean success = ftpClient.storeFile(fileName, fis);
>if (!success) {
>// this is false if "NoSessionReuseRequired" is not set
>}
> Now my question is if it is generally possible to connect to a server
> with "TLSProtocol TLSv1" or "TLSProtocol SSLv23" without the
> "NoSessionReuseRequired" parameter? Could someone provide a piece of
> example code for this?



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