[jira] [Commented] (TRANSACTION-34) Connection handle is not set in MapManagedConnection.close()
[
https://issues.apache.org/jira/browse/TRANSACTION-34?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=17544114#comment-17544114
]
Mini B commented on TRANSACTION-34:
---
We are observing connection leak when a database work is done on
afterCompletion() of java transaction, this ticket seems to related.
> Connection handle is not set in MapManagedConnection.close()
>
>
> Key: TRANSACTION-34
> URL: https://issues.apache.org/jira/browse/TRANSACTION-34
> Project: Commons Transaction
> Issue Type: Bug
>Affects Versions: 1.2
> Environment: all
>Reporter: Boris Kobilkovsky
>Priority: Minor
>
> Setting a connection handle on close is an explicit requirement of JTA spec.
> Not setting the handle leads to memory leaks and incorrect connection state
> in transaction managers.
> The fix is trivial. Below is the fixed correct implementation of
> org.apache.commons.transaction.memory.jca.MapManagedConnection.close()
>public void close() {
> ConnectionEvent event = new ConnectionEvent(this,
> ConnectionEvent.CONNECTION_CLOSED);
> //the fix start
> event.setConnectionHandle(connection);
> ///the fix end
> for (Iterator it = listeners.iterator(); it.hasNext();) {
> ((ConnectionEventListener) it.next()).connectionClosed(event);
> }
> connection.invalidate();
> connection = null;
> }
--
This message was sent by Atlassian Jira
(v8.20.7#820007)
[jira] [Commented] (IO-538) Add Non Synchronized CharArrayWriter
[
https://issues.apache.org/jira/browse/IO-538?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=17280928#comment-17280928
]
Ashish b commented on IO-538:
-
[~belugabehr] [~britter]
Please assign me the jira
> Add Non Synchronized CharArrayWriter
> -
>
> Key: IO-538
> URL: https://issues.apache.org/jira/browse/IO-538
> Project: Commons IO
> Issue Type: New Feature
> Components: Streams/Writers
>Affects Versions: 2.5
>Reporter: David Mollitor
>Priority: Minor
> Attachments: IO-538.1.patch
>
>
> There currently exists {{StringBuilderWriter}}. This implementation, as an
> alternative to java.io.StringWriter, provides an un-synchronized (i.e. for
> use in a single thread) implementation for better performance.
> It would be nice if there way one for CharArrayWriter as well.
> https://www.igorkromin.net/index.php/2015/08/20/java-stringwriter-vs-chararraywriter-which-one-to-choose-for-performance/
--
This message was sent by Atlassian Jira
(v8.3.4#803005)
[jira] [Commented] (IO-707) Add optional early error detection as postcondition check
[ https://issues.apache.org/jira/browse/IO-707?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=17280911#comment-17280911 ] Ashish b commented on IO-707: - [~xf01213] Can you assign the issue to me ? > Add optional early error detection as postcondition check > - > > Key: IO-707 > URL: https://issues.apache.org/jira/browse/IO-707 > Project: Commons IO > Issue Type: Improvement > Components: Utilities >Affects Versions: 2.8.0 >Reporter: Boris Unckel >Priority: Major > Time Spent: 1h 50m > Remaining Estimate: 0h > > The current version does not include an optional way to detect errors with > the underlying filesystem and/or logic early. > Due to performance reason and/or design decision, the result of delete or > create directories/files does not include a check wheter the delete or create > was successful. It "only" relies on trust to the underlying operations of the > JDK and/or the completeness of own unit tests. > To have the option to check things, without having additional commons-io > proprietary options and without a performance impact for regular operations > the Java 1.4 keyword "assert" should be used. > Current project profits in case of detail analysis. Downstream projects > having own unit tests for IO will profit. > PR with proposal will follow. -- This message was sent by Atlassian Jira (v8.3.4#803005)
[jira] [Commented] (IO-719) PathUtils.copyDirectory() does not work when source and dest belong to different filesystems
[
https://issues.apache.org/jira/browse/IO-719?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=17280896#comment-17280896
]
Ashish b commented on IO-719:
-
Can you assign the Jira to me.
> PathUtils.copyDirectory() does not work when source and dest belong to
> different filesystems
>
>
> Key: IO-719
> URL: https://issues.apache.org/jira/browse/IO-719
> Project: Commons IO
> Issue Type: Bug
> Components: Utilities
>Affects Versions: 2.8.0
> Environment: Java 8, Linux
>Reporter: Andrew Shcheglov
>Priority: Major
>
> This code:
> {code:java}
> @Test
> public void pathUtilsCopyDirFailure() throws IOException {
> FileSystem fs1 = Jimfs.newFileSystem();
> Path srcDir = fs1.getPath("srcDir");
> // Create files/dirs in srcDir
> Path targetDir = Paths.get("targetDir");
> PathUtils.copyDirectory(srcDir, targetDir);
> }
> {code}
> throws exception:
> {noformat}
> java.nio.file.ProviderMismatchException
> at java.base/sun.nio.fs.UnixPath.toUnixPath(UnixPath.java:198)
> at java.base/sun.nio.fs.UnixPath.resolve(UnixPath.java:410)
> at java.base/sun.nio.fs.UnixPath.resolve(UnixPath.java:43)
> at
> org.apache.commons.io.file.CopyDirectoryVisitor.preVisitDirectory(CopyDirectoryVisitor.java:130)
> at
> org.apache.commons.io.file.CopyDirectoryVisitor.preVisitDirectory(CopyDirectoryVisitor.java:36)
> at java.base/java.nio.file.Files.walkFileTree(Files.java:2731)
> at java.base/java.nio.file.Files.walkFileTree(Files.java:2796)
> at
> org.apache.commons.io.file.PathUtils.visitFileTree(PathUtils.java:687)
> at
> org.apache.commons.io.file.PathUtils.copyDirectory(PathUtils.java:196)
> {noformat}
--
This message was sent by Atlassian Jira
(v8.3.4#803005)
[jira] [Comment Edited] (IO-719) PathUtils.copyDirectory() does not work when source and dest belong to different filesystems
[
https://issues.apache.org/jira/browse/IO-719?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=17280896#comment-17280896
]
Ashish b edited comment on IO-719 at 2/8/21, 9:46 AM:
--
[~ashcheglov] [~ggregory]
Can you assign the Jira to me.
was (Author: beashish):
Can you assign the Jira to me.
> PathUtils.copyDirectory() does not work when source and dest belong to
> different filesystems
>
>
> Key: IO-719
> URL: https://issues.apache.org/jira/browse/IO-719
> Project: Commons IO
> Issue Type: Bug
> Components: Utilities
>Affects Versions: 2.8.0
> Environment: Java 8, Linux
>Reporter: Andrew Shcheglov
>Priority: Major
>
> This code:
> {code:java}
> @Test
> public void pathUtilsCopyDirFailure() throws IOException {
> FileSystem fs1 = Jimfs.newFileSystem();
> Path srcDir = fs1.getPath("srcDir");
> // Create files/dirs in srcDir
> Path targetDir = Paths.get("targetDir");
> PathUtils.copyDirectory(srcDir, targetDir);
> }
> {code}
> throws exception:
> {noformat}
> java.nio.file.ProviderMismatchException
> at java.base/sun.nio.fs.UnixPath.toUnixPath(UnixPath.java:198)
> at java.base/sun.nio.fs.UnixPath.resolve(UnixPath.java:410)
> at java.base/sun.nio.fs.UnixPath.resolve(UnixPath.java:43)
> at
> org.apache.commons.io.file.CopyDirectoryVisitor.preVisitDirectory(CopyDirectoryVisitor.java:130)
> at
> org.apache.commons.io.file.CopyDirectoryVisitor.preVisitDirectory(CopyDirectoryVisitor.java:36)
> at java.base/java.nio.file.Files.walkFileTree(Files.java:2731)
> at java.base/java.nio.file.Files.walkFileTree(Files.java:2796)
> at
> org.apache.commons.io.file.PathUtils.visitFileTree(PathUtils.java:687)
> at
> org.apache.commons.io.file.PathUtils.copyDirectory(PathUtils.java:196)
> {noformat}
--
This message was sent by Atlassian Jira
(v8.3.4#803005)
[jira] [Commented] (COMPRESS-327) Support in-memory processing for ZipFile
[ https://issues.apache.org/jira/browse/COMPRESS-327?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=15570033#comment-15570033 ] Peter B. commented on COMPRESS-327: --- [~bodewig] this is great news! Any time-wise plans on release holding this feature you could share with us? > Support in-memory processing for ZipFile > > > Key: COMPRESS-327 > URL: https://issues.apache.org/jira/browse/COMPRESS-327 > Project: Commons Compress > Issue Type: New Feature >Reporter: Brett Kail >Priority: Minor > Fix For: 1.13 > > Attachments: > 0001-Add-a-SeekableInputStream-and-some-subclasses-that-Z.patch > > > ZipFile (and SevenZFile) currently require a File argument, but it would be > nice to support in-memory byte buffers rather than requiring temp files. > Perhaps create a new SeekableInputStream class (or SeekableDataInput > interface) and add corresponding constructors. > For convenience, perhaps also add a utility class that wraps a ByteBuffer > and/or byte[] and implements the new interface. > (The sevenz package appears to have a similar limitation, so it might make > sense to add the support there at the same time, but I personally don't have > a need for that.) -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Commented] (IO-376) FileUtils.copyFile for the locked file (windows)
[
https://issues.apache.org/jira/browse/IO-376?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13668107#comment-13668107
]
Peter B. commented on IO-376:
-
I got it solved by slightly modified solution described in:
http://mohammed-technical.blogspot.de/2011/02/how-to-read-file-without-locking-in.html
as he reads only byte by byte, where I read to buffer to speed up things up to
RandomAccessFile.length().
Moreover as I already mentioned, similar functionality is already present in
the:
http://commons.apache.org/proper/commons-io/javadocs/api-2.4/org/apache/commons/io/input/Tailer.html
so it should not be such a big deal.
> FileUtils.copyFile for the locked file (windows)
>
>
> Key: IO-376
> URL: https://issues.apache.org/jira/browse/IO-376
> Project: Commons IO
> Issue Type: New Feature
> Components: Streams/Writers
>Affects Versions: 2.4
> Environment: Windows
>Reporter: Peter B.
>Priority: Minor
>
> The use case:
> - log4j writes to the file using RollingFileAppender.
> - in parallel I need to read the file contents for later manipulation
> (storing it's contents elsewhere)
> Problem on windows:
> - I open FileInputStream for reading from file
> - when using IOUtils.copy(InputStream input, OutputStream output) exception
> is thrown:
> {code}
> java.io.IOException: The process cannot access the file because another
> process has locked a portion of the file
> {code}
> It would be great to have API enabling to copy contents of the locked file
> (on windows) to OutputStream.
> The method available in the API currently:
> {code:java}
> FileUtils.copyFile(File input, OutputStream output)
> {code}
> does the job, except for the files that are locked (in the windows
> environment) as they're currently written to.
> Some of the functionality is already in use in the: Tailer
> However (non-bloked) copying full contents is not provided.
> I'd need to retrieve a snapshot of the file.
> Not sure about the right API, but generally I see 2 options:
> - custom (File)InputSteam implementation or maybe
> - custom FileUtils.copyFile(File input, OutputStream output)
--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators
For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] [Commented] (IO-376) FileUtils.copyFile for the locked file (windows)
[
https://issues.apache.org/jira/browse/IO-376?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13668107#comment-13668107
]
Peter B. commented on IO-376:
-
I got it solved by slightly modified solution described in:
http://mohammed-technical.blogspot.de/2011/02/how-to-read-file-without-locking-in.html
as he reads only byte by byte, where I read to buffer to speed up things up to
RandomAccessFile.length().
Moreover as I already mentioned, similar functionality is already present in
the:
http://commons.apache.org/proper/commons-io/javadocs/api-2.4/org/apache/commons/io/input/Tailer.html
so it should not be such a big deal.
> FileUtils.copyFile for the locked file (windows)
>
>
> Key: IO-376
> URL: https://issues.apache.org/jira/browse/IO-376
> Project: Commons IO
> Issue Type: New Feature
> Components: Streams/Writers
>Affects Versions: 2.4
> Environment: Windows
>Reporter: Peter B.
>Priority: Minor
>
> The use case:
> - log4j writes to the file using RollingFileAppender.
> - in parallel I need to read the file contents for later manipulation
> (storing it's contents elsewhere)
> Problem on windows:
> - I open FileInputStream for reading from file
> - when using IOUtils.copy(InputStream input, OutputStream output) exception
> is thrown:
> {code}
> java.io.IOException: The process cannot access the file because another
> process has locked a portion of the file
> {code}
> It would be great to have API enabling to copy contents of the locked file
> (on windows) to OutputStream.
> The method available in the API currently:
> {code:java}
> FileUtils.copyFile(File input, OutputStream output)
> {code}
> does the job, except for the files that are locked (in the windows
> environment) as they're currently written to.
> Some of the functionality is already in use in the: Tailer
> However (non-bloked) copying full contents is not provided.
> I'd need to retrieve a snapshot of the file.
> Not sure about the right API, but generally I see 2 options:
> - custom (File)InputSteam implementation or maybe
> - custom FileUtils.copyFile(File input, OutputStream output)
--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators
For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] [Comment Edited] (IO-376) FileUtils.copyFile for the locked file (windows)
[
https://issues.apache.org/jira/browse/IO-376?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13668107#comment-13668107
]
Peter B. edited comment on IO-376 at 5/28/13 5:45 AM:
--
I got it solved by slightly modified solution described in:
http://mohammed-technical.blogspot.de/2011/02/how-to-read-file-without-locking-in.html
as the guy reads only byte by byte, where I read to buffer to speed up things
up to RandomAccessFile.length().
Moreover as I already mentioned, similar functionality is already present in
the:
http://commons.apache.org/proper/commons-io/javadocs/api-2.4/org/apache/commons/io/input/Tailer.html
so it should not be such a big deal.
was (Author: typek_pb):
I got it solved by slightly modified solution described in:
http://mohammed-technical.blogspot.de/2011/02/how-to-read-file-without-locking-in.html
as he reads only byte by byte, where I read to buffer to speed up things up to
RandomAccessFile.length().
Moreover as I already mentioned, similar functionality is already present in
the:
http://commons.apache.org/proper/commons-io/javadocs/api-2.4/org/apache/commons/io/input/Tailer.html
so it should not be such a big deal.
> FileUtils.copyFile for the locked file (windows)
>
>
> Key: IO-376
> URL: https://issues.apache.org/jira/browse/IO-376
> Project: Commons IO
> Issue Type: New Feature
> Components: Streams/Writers
>Affects Versions: 2.4
> Environment: Windows
>Reporter: Peter B.
>Priority: Minor
>
> The use case:
> - log4j writes to the file using RollingFileAppender.
> - in parallel I need to read the file contents for later manipulation
> (storing it's contents elsewhere)
> Problem on windows:
> - I open FileInputStream for reading from file
> - when using IOUtils.copy(InputStream input, OutputStream output) exception
> is thrown:
> {code}
> java.io.IOException: The process cannot access the file because another
> process has locked a portion of the file
> {code}
> It would be great to have API enabling to copy contents of the locked file
> (on windows) to OutputStream.
> The method available in the API currently:
> {code:java}
> FileUtils.copyFile(File input, OutputStream output)
> {code}
> does the job, except for the files that are locked (in the windows
> environment) as they're currently written to.
> Some of the functionality is already in use in the: Tailer
> However (non-bloked) copying full contents is not provided.
> I'd need to retrieve a snapshot of the file.
> Not sure about the right API, but generally I see 2 options:
> - custom (File)InputSteam implementation or maybe
> - custom FileUtils.copyFile(File input, OutputStream output)
--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators
For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] [Comment Edited] (NET-408) problem connecting to ProFTPD with FTPES
[
https://issues.apache.org/jira/browse/NET-408?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13647401#comment-13647401
]
Andreas B. edited comment on NET-408 at 5/2/13 9:53 AM:
@[~cbustamante]: I guess this is working for you, because you are setting
_'force_local_data_ssl=NO'_, which allows data to be sent in plain.
This is not an option for me, and the error still exists for me. (tested with
jdk 1.6 and 1.7, commons-net-3.1.jar and 3.2, vsftp 2.2.x)
Error message: _"Error: 522 SSL connection failed; session reuse required: see
require_ssl_reuse option in vsftpd.conf man page"_
However, _cyberduck_ had the same issue and were obviously able to solve it.
Their code is available, so maybe you can get a hint there.
See: http://trac.cyberduck.ch/ticket/5087
was (Author: burnyguru):
@[~cbustamante]: I guess this is working for you, because you are setting
_'force_local_data_ssl=NO'_, which allows data to be sent in plain.
This is not an option for me, and the error still exists for me. (tested with
jdk 1.6 and 1.7, commons-net-3.1.jar and 3.2, vsftp 2.2.x)
However, _cyberduck_ had the same issue and were obviously able to solve it.
Their code is available, so maybe you can get a hint there.
See: http://trac.cyberduck.ch/ticket/5087
> 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, 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 is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators
For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] [Commented] (NET-408) problem connecting to ProFTPD with FTPES
[
https://issues.apache.org/jira/browse/NET-408?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13647401#comment-13647401
]
Andreas B. commented on NET-408:
@[~cbustamante]: I guess this is working for you, because you are setting
_'force_local_data_ssl=NO'_, which allows data to be sent in plain.
This is not an option for me, and the error still exists for me. (tested with
jdk 1.6 and 1.7, commons-net-3.1.jar and 3.2, vsftp 2.2.x)
However, _cyberduck_ had the same issue and were obviously able to solve it.
Their code is available, so maybe you can get a hint there.
See: http://trac.cyberduck.ch/ticket/5087
> 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, 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 is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators
For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] [Updated] (IO-376) FileUtils.copyFile for the locked file (windows)
[
https://issues.apache.org/jira/browse/IO-376?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Peter B. updated IO-376:
Description:
The use case:
- log4j writes to the file using RollingFileAppender.
- in parallel I need to read the file contents for later manipulation (storing
it's contents elsewhere)
Problem on windows:
- I open FileInputStream for reading from file
- when using IOUtils.copy(InputStream input, OutputStream output) exception is
thrown:
{code}
java.io.IOException: The process cannot access the file because another process
has locked a portion of the file
{code}
It would be great to have API enabling to copy contents of the locked file (on
windows) to OutputStream.
The method available in the API currently:
{code:java}
FileUtils.copyFile(File input, OutputStream output)
{code}
does the job, except for the files that are locked (in the windows environment)
as they're currently written to.
Some of the functionality is already in use in the: Tailer
However (non-bloked) copying full contents is not provided.
I'd need to retrieve a snapshot of the file.
Not sure about the right API, but generally I see 2 options:
- custom (File)InputSteam implementation or maybe
- custom FileUtils.copyFile(File input, OutputStream output)
was:
The use case:
- log4j writes to the file using RollingFileAppender.
- in parallel I need to read the file contents for later manipulation (storing
it's contents elsewhere)
Problem on windows:
- I open FileInputStream for reading from file
- when using IOUtils.copy(InputStream input, OutputStream output) exception is
thrown:
java.io.IOException: The process cannot access the file because another process
has locked a portion of the file
It would be great to have API enabling to copy contents of the locked file (on
windows) to OutputStream.
The method available in the API currently:
copyFile(File input, OutputStream output)
does the job, except for the files that are locked (in the windows environment)
as they're currently written to.
Some of the functionality is already in use in the: Tailer
However (non-bloked) copying full contents is not provided.
I'd need to retrieve a snapshot of the file.
Not sure about the right API, but generally I see 2 options:
- custom (File)InputSteam implementation or maybe
- custom FileUtils.copyFile(File input, OutputStream output)
> FileUtils.copyFile for the locked file (windows)
>
>
> Key: IO-376
> URL: https://issues.apache.org/jira/browse/IO-376
> Project: Commons IO
> Issue Type: New Feature
> Components: Streams/Writers
>Affects Versions: 2.4
> Environment: Windows
>Reporter: Peter B.
>Priority: Minor
>
> The use case:
> - log4j writes to the file using RollingFileAppender.
> - in parallel I need to read the file contents for later manipulation
> (storing it's contents elsewhere)
> Problem on windows:
> - I open FileInputStream for reading from file
> - when using IOUtils.copy(InputStream input, OutputStream output) exception
> is thrown:
> {code}
> java.io.IOException: The process cannot access the file because another
> process has locked a portion of the file
> {code}
> It would be great to have API enabling to copy contents of the locked file
> (on windows) to OutputStream.
> The method available in the API currently:
> {code:java}
> FileUtils.copyFile(File input, OutputStream output)
> {code}
> does the job, except for the files that are locked (in the windows
> environment) as they're currently written to.
> Some of the functionality is already in use in the: Tailer
> However (non-bloked) copying full contents is not provided.
> I'd need to retrieve a snapshot of the file.
> Not sure about the right API, but generally I see 2 options:
> - custom (File)InputSteam implementation or maybe
> - custom FileUtils.copyFile(File input, OutputStream output)
--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators
For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] [Created] (IO-376) FileUtils.copyFile for the locked file (windows)
Peter B. created IO-376: --- Summary: FileUtils.copyFile for the locked file (windows) Key: IO-376 URL: https://issues.apache.org/jira/browse/IO-376 Project: Commons IO Issue Type: New Feature Components: Streams/Writers Affects Versions: 2.4 Environment: Windows Reporter: Peter B. Priority: Minor The use case: - log4j writes to the file using RollingFileAppender. - in parallel I need to read the file contents for later manipulation (storing it's contents elsewhere) Problem on windows: - I open FileInputStream for reading from file - when using IOUtils.copy(InputStream input, OutputStream output) exception is thrown: java.io.IOException: The process cannot access the file because another process has locked a portion of the file It would be great to have API enabling to copy contents of the locked file (on windows) to OutputStream. The method available in the API currently: copyFile(File input, OutputStream output) does the job, except for the files that are locked (in the windows environment) as they're currently written to. Some of the functionality is already in use in the: Tailer However (non-bloked) copying full contents is not provided. I'd need to retrieve a snapshot of the file. Not sure about the right API, but generally I see 2 options: - custom (File)InputSteam implementation or maybe - custom FileUtils.copyFile(File input, OutputStream output) -- This message is automatically generated by JIRA. If you think it was sent incorrectly, please contact your JIRA administrators For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] [Commented] (NET-495) Unsupported record version Unknown-48.48 - commons-net-3.1.jar
[ https://issues.apache.org/jira/browse/NET-495?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13607677#comment-13607677 ] Andreas B. commented on NET-495: Seems to be fixed in commons-net-3.2.jar. Although there is no exception thrown, I still see the same error in the log when using -Djavax.net.debug=all. Log-Output: = main, called close() main, called closeInternal(true) main, SEND TLSv1 ALERT: warning, description = close_notify Padded plaintext before ENCRYPTION: len = 32 : 01 00 80 0B 3F A9 CD FD 8A 6A 26 EB 22 96 76 87 ?j&.".v. 0010: 7B 85 48 BC 34 9F 09 09 09 09 09 09 09 09 09 09 ..H.4... main, WRITE: TLSv1 Alert, length = 32 [Raw write]: length = 37 : 15 03 01 00 20 A0 FA 91 F8 3C 60 ED 1F 53 D8 76 <`..S.v 0010: B9 29 02 B2 1E A9 27 D7 90 F4 C8 41 99 DF C5 D4 .)'A 0020: D6 C1 8F 18 AD . main, called closeSocket(selfInitiated) main, waiting for close_notify or alert: state 5 [Raw read]: length = 5 : 35 30 30 20 4F 500 O main, Exception while waiting for close javax.net.ssl.SSLException: Unsupported record version Unknown-48.48 > Unsupported record version Unknown-48.48 - commons-net-3.1.jar > -- > > Key: NET-495 > URL: https://issues.apache.org/jira/browse/NET-495 > Project: Commons Net > Issue Type: Bug > Components: FTP >Affects Versions: 3.1 > Environment: Windows XP, Windows 7, HP-UX >Reporter: Deepak Pant > Labels: commons-net-3.1.jar, ftp, ftps > Attachments: FTPSClient_Error_Dump.txt > > > FTPSClient bundled in "commons-net-3.1.jar" returns "Unsupported record > version Unknown-48.48" error when I try to FTP a zero byte file. This error > doesn't come when we use "commons-net-2.0.jar" file. > javax.net.ssl.SSLException: Unsupported record version Unknown-48.48 > at > com.sun.net.ssl.internal.ssl.InputRecord.readV3Record(InputRecord.java:375) > at com.sun.net.ssl.internal.ssl.InputRecord.read(InputRecord.java:360) > at > com.sun.net.ssl.internal.ssl.SSLSocketImpl.readRecord(SSLSocketImpl.java:830) > at > com.sun.net.ssl.internal.ssl.SSLSocketImpl.readDataRecord(SSLSocketImpl.java:787) > at > com.sun.net.ssl.internal.ssl.AppInputStream.read(AppInputStream.java:75) > at sun.nio.cs.StreamDecoder.readBytes(StreamDecoder.java:264) > at sun.nio.cs.StreamDecoder.implRead(StreamDecoder.java:306) > at sun.nio.cs.StreamDecoder.read(StreamDecoder.java:158) > at java.io.InputStreamReader.read(InputStreamReader.java:167) > at java.io.BufferedReader.fill(BufferedReader.java:136) > at java.io.BufferedReader.readLine(BufferedReader.java:299) > at java.io.BufferedReader.readLine(BufferedReader.java:362) > at org.apache.commons.net.ftp.FTP.__getReply(FTP.java:310) > at org.apache.commons.net.ftp.FTP.__getReply(FTP.java:290) > at org.apache.commons.net.ftp.FTP.getReply(FTP.java:637) > at > org.apache.commons.net.ftp.FTPClient.completePendingCommand(FTPClient.java:1637) > at org.apache.commons.net.ftp.FTPClient._storeFile(FTPClient.java:599) > at > org.apache.commons.net.ftp.FTPClient.__storeFile(FTPClient.java:557) > at org.apache.commons.net.ftp.FTPClient.storeFile(FTPClient.java:1795) > at FTPSExample.main(FTPSExample.java:173) -- This message is automatically generated by JIRA. If you think it was sent incorrectly, please contact your JIRA administrators For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] [Closed] (CLI-235) OptionBuilder wrong design
[
https://issues.apache.org/jira/browse/CLI-235?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Sergey B. closed CLI-235.
-
Resolution: Duplicate
> OptionBuilder wrong design
> --
>
> Key: CLI-235
> URL: https://issues.apache.org/jira/browse/CLI-235
> Project: Commons CLI
> Issue Type: Bug
> Components: Options definition
>Affects Versions: 1.2
>Reporter: Sergey B.
>Priority: Minor
> Labels: OptionBuilder
>
> OptionBuilder uses static variables to do its work. That's why it is not
> thread safe.
> More than that, static builder methods doesn't conform to Java good style of
> accessing static members. Such members belong to the class and must be
> accessed in static way.
> Consider creating new builder-like class like that:
> {code:java}
> OptionBuilder optionBuilder = OptionBuilder.newInstance();
> options.add(optionBuilder.withDescription().hasArg().create());
> options.add(optionBuilder.withDescription().hasArg().create());
> options.add(optionBuilder.withDescription().hasArg().create());
> {code}
--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators
For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] [Created] (CLI-235) OptionBuilder wrong design
Sergey B. created CLI-235:
-
Summary: OptionBuilder wrong design
Key: CLI-235
URL: https://issues.apache.org/jira/browse/CLI-235
Project: Commons CLI
Issue Type: Bug
Components: Options definition
Affects Versions: 1.2
Reporter: Sergey B.
Priority: Minor
OptionBuilder uses static variables to do its work. That's why it is not thread
safe.
More than that, static builder methods doesn't conform to Java good style of
accessing static members. Such members belong to the class and must be accessed
in static way.
Consider creating new builder-like class like that:
{code:java}
OptionBuilder optionBuilder = OptionBuilder.newInstance();
options.add(optionBuilder.withDescription().hasArg().create());
options.add(optionBuilder.withDescription().hasArg().create());
options.add(optionBuilder.withDescription().hasArg().create());
{code}
--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators
For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] [Created] (SANSELAN-50) Support for WEBP Image Format
Support for WEBP Image Format - Key: SANSELAN-50 URL: https://issues.apache.org/jira/browse/SANSELAN-50 Project: Commons Sanselan Issue Type: New Feature Reporter: Wilian C. B. A new image format designed by Google is emerging, it uses lossy compression. It is used to reduce image file size to speed up web page loading and its principal purpose is to supersede JPEG as the primary format for photographs on the web. It would be really good to add this new image format :-) -- This message is automatically generated by JIRA. For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] Updated: (CONFIGURATION-440) setProperty in XmlConfiguration escapes backslashes
[
https://issues.apache.org/jira/browse/CONFIGURATION-440?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
B updated CONFIGURATION-440:
Description:
When setPropery sets a new value that has backslashes (like path), backslashes
are escaped. When that value is loaded again, all backslashes are duplicated.
Following test keeps failing. Don't know if there is some kind of formatting.
public class XmlConfigurationTest {
private static final String XML_CONFIGURATION_PATH =
"resources/xml/config.xml";
private static final String PATH1 = "c:\\temp\\path\\file.txt";
private static final String PATH2 = "c:\\temp1\\path1\\file1.txt";
private static final String PATH3 = "c:\\temp2\\path2\\file2.txt";
@Test
public void testXmlConfiguration() throws IOException {
File resourceFile = null;
try {
assertNotNull(_bundleContext);
resourceFile = new File(SystemUtils.getTargetDirectory(),
XML_CONFIGURATION_PATH);
assertTrue(resourceFile.getParentFile().mkdirs());
String value = null;
XMLConfiguration configuration = new XMLConfiguration();
configuration.setExpressionEngine(new XPathExpressionEngine());
configuration.setDelimiterParsingDisabled(true);
configuration.addProperty(" key1", PATH1);
configuration.setProperty(" key2", PATH2);
configuration.save(resourceFile);
/* All values are saved with non escaped backslashes */
value = configuration.getString("key1");
assertEquals(value, PATH1);
value = configuration.getString("key2");
assertEquals(value, PATH2);
/*
* Set again same property with different value. Setting property
* with this configuration will escape backslashes. Even though
* assert will pass, path with escaped backslashes will be written
* in a file (don't know if it is setProperty or save that is
causing troubles).
*/
configuration.setProperty(" key2", PATH3);
configuration.save(resourceFile);
value = configuration.getString("key2");
assertEquals(value, PATH3);
/*
* Create new configuration and load values from previously saved
* file.
*/
XMLConfiguration newConfiguration = new XMLConfiguration();
newConfiguration.setExpressionEngine(new XPathExpressionEngine());
newConfiguration.setDelimiterParsingDisabled(true);
newConfiguration.load(resourceFile);
/*
* At this point, configuration will load escaped backslashes, and
* the test will fail.
*/
value = newConfiguration.getString("key2");
assertEquals(value, PATH3);
} catch (Throwable e) {
e.printStackTrace();
fail(e.getLocalizedMessage());
} finally {
/*
* Delete resource file
*/
resourceFile.delete();
}
}
}
was:
When setPropery sets a new value that has backslashes (like path), backslashes
are escaped. When that value is loaded again, all backslashes are duplicated.
public class XmlConfigurationTest {
private static final String XML_CONFIGURATION_PATH =
"resources/xml/config.xml";
private static final String PATH1 = "c:\\temp\\path\\file.txt";
private static final String PATH2 = "c:\\temp1\\path1\\file1.txt";
private static final String PATH3 = "c:\\temp2\\path2\\file2.txt";
@Test
public void testXmlConfiguration() throws IOException {
File resourceFile = null;
try {
assertNotNull(_bundleContext);
resourceFile = new File(SystemUtils.getTargetDirectory(),
XML_CONFIGURATION_PATH);
assertTrue(resourceFile.getParentFile().mkdirs());
String value = null;
XMLConfiguration configuration = new XMLConfiguration();
configuration.setExpressionEngine(new XPathExpressionEngine());
configuration.setDelimiterParsingDisabled(true);
configuration.addProperty(" key1", PATH1);
configuration.setProperty(" key2", PATH2);
configuration.save(resourceFile);
/* All values are saved with non escaped backslashes */
value = configuration.getString("key1");
assertEquals(value, PATH1);
value = configuration.getString("key2");
assertEquals(value, PATH2);
/*
* Set again same property with different value. Setting property
* with this configuration will escape backslashes. Even though
* assert will pass, path with escaped backslashes will be written
* in a file (don't k
[jira] Created: (CONFIGURATION-440) setProperty in XmlConfiguration escapes backslashes
setProperty in XmlConfiguration escapes backslashes
---
Key: CONFIGURATION-440
URL: https://issues.apache.org/jira/browse/CONFIGURATION-440
Project: Commons Configuration
Issue Type: Bug
Components: Build
Affects Versions: 1.6
Environment: Windows 7
Reporter: B
Fix For: 2.0
When setPropery sets a new value that has backslashes (like path), backslashes
are escaped. When that value is loaded again, all backslashes are duplicated.
public class XmlConfigurationTest {
private static final String XML_CONFIGURATION_PATH =
"resources/xml/config.xml";
private static final String PATH1 = "c:\\temp\\path\\file.txt";
private static final String PATH2 = "c:\\temp1\\path1\\file1.txt";
private static final String PATH3 = "c:\\temp2\\path2\\file2.txt";
@Test
public void testXmlConfiguration() throws IOException {
File resourceFile = null;
try {
assertNotNull(_bundleContext);
resourceFile = new File(SystemUtils.getTargetDirectory(),
XML_CONFIGURATION_PATH);
assertTrue(resourceFile.getParentFile().mkdirs());
String value = null;
XMLConfiguration configuration = new XMLConfiguration();
configuration.setExpressionEngine(new XPathExpressionEngine());
configuration.setDelimiterParsingDisabled(true);
configuration.addProperty(" key1", PATH1);
configuration.setProperty(" key2", PATH2);
configuration.save(resourceFile);
/* All values are saved with non escaped backslashes */
value = configuration.getString("key1");
assertEquals(value, PATH1);
value = configuration.getString("key2");
assertEquals(value, PATH2);
/*
* Set again same property with different value. Setting property
* with this configuration will escape backslashes. Even though
* assert will pass, path with escaped backslashes will be written
* in a file (don't know if it is setProperty or save that is
causing troubles).
*/
configuration.setProperty(" key2", PATH3);
configuration.save(resourceFile);
value = configuration.getString("key2");
assertEquals(value, PATH3);
/*
* Create new configuration and load values from previously saved
* file.
*/
XMLConfiguration newConfiguration = new XMLConfiguration();
newConfiguration.setExpressionEngine(new XPathExpressionEngine());
newConfiguration.setDelimiterParsingDisabled(true);
newConfiguration.load(resourceFile);
/*
* At this point, configuration will load escaped backslashes, and
* the test will fail.
*/
value = newConfiguration.getString("key2");
assertEquals(value, PATH3);
} catch (Throwable e) {
e.printStackTrace();
fail(e.getLocalizedMessage());
} finally {
/*
* Delete resource file
*/
resourceFile.delete();
}
}
}
--
This message is automatically generated by JIRA.
-
For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] Created: (MATH-504) LOESS interpolation & tricube fonction
LOESS interpolation & tricube fonction
--
Key: MATH-504
URL: https://issues.apache.org/jira/browse/MATH-504
Project: Commons Math
Issue Type: Bug
Affects Versions: 2.1
Environment: Win XP
Reporter: X. B.
Priority: Trivial
the doc for tricube fonction used in LOESS smooth() says :
* @return (1 - |x|3)3.
But I'dont see the absolute value for x.
Also, the "classical" tricube fonction (see
http://www.itl.nist.gov/div898/handbook/pmd/section1/pmd144.htm)
seems to return 0 if abs(x)>1.
In the code of the tricube method, It is apparently not the case...
private static double tricube(final double x) {
final double tmp = 1 - x * x * x;
return tmp * tmp * tmp;
}
--
This message is automatically generated by JIRA.
-
For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] Updated: (MATH-504) LOESS interpolation & tricube fonction
[
https://issues.apache.org/jira/browse/MATH-504?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
X. B. updated MATH-504:
---
Description:
the doc for tricube fonction used in LOESS smooth() says :
* @return (1 - |x|3)3.
But I'dont see the absolute value for x.
Also, the "classical" tricube fonction (see
http://www.itl.nist.gov/div898/handbook/pmd/section1/pmd144.htm)
seems to return 0 if abs( x )>1.
In the code of the tricube method, It is apparently not the case...
private static double tricube(final double x) {
final double tmp = 1 - x * x * x;
return tmp * tmp * tmp;
}
was:
the doc for tricube fonction used in LOESS smooth() says :
* @return (1 - |x|3)3.
But I'dont see the absolute value for x.
Also, the "classical" tricube fonction (see
http://www.itl.nist.gov/div898/handbook/pmd/section1/pmd144.htm)
seems to return 0 if abs(x)>1.
In the code of the tricube method, It is apparently not the case...
private static double tricube(final double x) {
final double tmp = 1 - x * x * x;
return tmp * tmp * tmp;
}
> LOESS interpolation & tricube fonction
> --
>
> Key: MATH-504
> URL: https://issues.apache.org/jira/browse/MATH-504
> Project: Commons Math
> Issue Type: Bug
>Affects Versions: 2.1
> Environment: Win XP
>Reporter: X. B.
>Priority: Trivial
> Labels: loess
> Original Estimate: 1h
> Remaining Estimate: 1h
>
> the doc for tricube fonction used in LOESS smooth() says :
> * @return (1 - |x|3)3.
> But I'dont see the absolute value for x.
> Also, the "classical" tricube fonction (see
> http://www.itl.nist.gov/div898/handbook/pmd/section1/pmd144.htm)
> seems to return 0 if abs( x )>1.
> In the code of the tricube method, It is apparently not the case...
> private static double tricube(final double x) {
> final double tmp = 1 - x * x * x;
> return tmp * tmp * tmp;
> }
--
This message is automatically generated by JIRA.
-
For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] Commented: (DBCP-290) java.sql.SQLException: Closed Statement
[
https://issues.apache.org/jira/browse/DBCP-290?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=12884062#action_12884062
]
Basavesh B commented on DBCP-290:
-
Dear Jira,
I am facing the same issue as what you are reported in the Forum. I would
appreciate if you can let me know how this was resolved. Thanks in Advance.
We are using WAS 6.0 in the production environment and having this problem.
Here is the log.
[6/30/10 10:08:00:833 EDT] 0034 SystemOut O If Last case
[6/30/10 10:08:00:834 EDT] 0034 E StatementCallback;
uncategorized SQLException for SQL [SELECT count(*) FROM USER WHERE
UPPER(USER_ID) = UPPER('cj4') ]; SQL state [null]; error code [0];
DSRA9110E: Connection is closed.; nested exception is
com.ibm.websphere.ce.cm.ObjectClosedException: DSRA9110E: Connection is
closed.
org.springframework.jdbc.UncategorizedSQLException: StatementCallback;
uncategorized SQLException for SQL [SELECT count(*) FROM VPT.VPT_USER WHERE
UPPER(USER_ID) = UPPER('zmmicj4') ]; SQL state [null]; error code [0];
DSRA9110E: Connection is closed.; nested exception is
com.ibm.websphere.ce.cm.ObjectClosedException: DSRA9110E: Connection is
closed.
at
org.springframework.jdbc.support.SQLStateSQLExceptionTranslator.translate(SQ
LStateSQLExceptionTranslator.java:124)
at
org.springframework.jdbc.support.SQLErrorCodeSQLExceptionTranslator.translat
e(SQLErrorCodeSQLExceptionTranslator.java:322)
at
org.springframework.jdbc.core.JdbcTemplate.execute(JdbcTemplate.java:407)
at
org.springframework.jdbc.core.JdbcTemplate.query(JdbcTemplate.java:458)
at
org.springframework.jdbc.core.JdbcTemplate.query(JdbcTemplate.java:466)
at
org.springframework.jdbc.core.JdbcTemplate.queryForObject(JdbcTemplate.java:
474)
at
org.springframework.jdbc.core.JdbcTemplate.queryForObject(JdbcTemplate.java:
479)
at
org.springframework.jdbc.core.JdbcTemplate.queryForInt(JdbcTemplate.java:488
)
at com.hbc.vp.daos.LoginDAOImpl.getUserCount(LoginDAOImpl.java:142)
at com.hbc.vp.daos.LoginDAOImpl.getUserCount(LoginDAOImpl.java:112)
at
com.hbc.vp.services.LoginService.authenticateUser(LoginService.java:245)
at
com.hbc.vp.controllers.LoginController.login(LoginController.java:131)
at sun.reflect.GeneratedMethodAccessor411.invoke(Unknown Source)
at
sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl
.java:37)
Thanks
Basavesh
> java.sql.SQLException: Closed Statement
>
>
> Key: DBCP-290
> URL: https://issues.apache.org/jira/browse/DBCP-290
> Project: Commons Dbcp
> Issue Type: Bug
>Affects Versions: 1.2.2
>Reporter: kan
> Fix For: 1.3
>
>
> We are getting below exception in production randomly..Using Spring(2.5) JDBC
> for all our DB related functionality.We don't handle any DB resources
> directly.everything thru Spring JDBC template. This app was running fine in
> Weblogic but after migrating to Tomcat6+DBCP(1.2.2) we are seeing the below
> exception.
> We also looked our code base for any threading or concurrency issues..we were
> not able spot any issues.
> I have observed one more thing..why checkOpen in DelegatingPreparedStatement
> didn't catch this but OracleStatement thinks the statement is closed.
> Is it bcos the DBCP is returing the closed connection? (DBCP-273)
> Caused by: org.springframework.jdbc.UncategorizedSQLException:
> PreparedStatementCallback; uncategorized SQLException for SQL [INSERT INTO
> AUDIT_TRAIL ( DEAL_ID , AUDIT_TRAIL_ID ) VALUES ( ?,? ) ]; SQL state [null];
> error code [17009]; Closed Statement; nested exception is
> java.sql.SQLException: Closed Statement
> at
> org.springframework.jdbc.support.SQLStateSQLExceptionTranslator.translate(SQLStateSQLExceptionTranslator.java:124)
>
> at
> org.springframework.jdbc.support.SQLErrorCodeSQLExceptionTranslator.translate(SQLErrorCodeSQLExceptionTranslator.java:322)
>
> at
> org.springframework.jdbc.core.JdbcTemplate.execute(JdbcTemplate.java:607)
> at
> org.springframework.jdbc.core.JdbcTemplate.update(JdbcTemplate.java:792)
> at
> org.springframework.jdbc.core.JdbcTemplate.update(JdbcTemplate.java:815)
> at
> org.springframework.jdbc.object.SqlUpdate.update(SqlUpdate.java:168)
> at com.dao.DealXAuditTrailDaoBase.insertDealXAuditTrailVoBase(Unknown
> Source)
> at com.deal.DealTO.insertAuditTrail(DealTO.java:183)
> at com.deal.DealTO.processAuditTrail(DealTO.java:168)
> at com.deal.DealTO.update(DealTO.java:110)
> at com.deal.DealTO$$FastClassByCGLIB$$fba55fe6.invoke()
> at net.sf.cglib.proxy.MethodProxy.invoke(MethodProxy.java:149)
>
