[jira] [Commented] (CSV-63) CSVPrinter always quotes empty string if it is the first on a line
[ https://issues.apache.org/jira/browse/CSV-63?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=14282093#comment-14282093 ] Trejkaz commented on CSV-63: Another vote for this feature from me. I see the need to quote it when there is one blank value to distinguish it from a blank line, but I don't see the need to quote it when there are 2+ values on the line, even if all values are blank. Another option which would have been fine by me is to write a single comma (it was one of the old tactics we used to use in the past to get around the same thing...) CSVPrinter always quotes empty string if it is the first on a line -- Key: CSV-63 URL: https://issues.apache.org/jira/browse/CSV-63 Project: Commons CSV Issue Type: Improvement Components: Printer Reporter: Sebb Priority: Minor Fix For: Patch Needed, 1.x CSVPrinter always quotes the empty string if it is the first on a line. This is inconsistent. -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Created] (VFS-558) java.lang.UnsupportedOperationException in FtpFileObject
L created VFS-558: - Summary: java.lang.UnsupportedOperationException in FtpFileObject Key: VFS-558 URL: https://issues.apache.org/jira/browse/VFS-558 Project: Commons VFS Issue Type: Bug Affects Versions: 2.0 Reporter: L I am getting the following exception in my code: java.lang.UnsupportedOperationException at java.util.Collections$UnmodifiableMap.remove(Collections.java:1345) at org.apache.commons.vfs2.provider.ftp.FtpFileObject.onChildrenChanged(FtpFileObject.java:271) at org.apache.commons.vfs2.provider.AbstractFileObject.childrenChanged(AbstractFileObject.java:240) at org.apache.commons.vfs2.provider.AbstractFileObject.notifyParent(AbstractFileObject.java:1931) at org.apache.commons.vfs2.provider.AbstractFileObject.handleCreate(AbstractFileObject.java:1577) at org.apache.commons.vfs2.provider.AbstractFileObject.moveTo(AbstractFileObject.java:1866) at org.apache.commons.vfs2.impl.DecoratedFileObject.moveTo(DecoratedFileObject.java:241) at org.apache.commons.vfs2.cache.OnCallRefreshFileObject.moveTo(OnCallRefreshFileObject.java:184) ... I guess it is caused by the fact that children field is set to EMPTY_FTP_FILE_MAP at the moment onChildrenChanged() is invoked. I also do not like line 1866 in AbstractFileObject.java. To me it looks like it might be the real cause of the problem: FileObjectUtils.getAbstractFileObject(destFile).handleCreate(getType()); Must it not be destFile.getType()? But even if I am right about AbstractFileObject.java:1866, FtpFileObject.onChildrenChanged() must be corrected as well. -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Commented] (LANG-1081) DiffBuilder.append(String, Object left, Object right) does not do a left.equals(right) check.
[ https://issues.apache.org/jira/browse/LANG-1081?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=14281840#comment-14281840 ] Jonathan Baker commented on LANG-1081: -- Submitted a pull request on GitHub.com. I hope this is the correct procedure. Please advise. DiffBuilder.append(String, Object left, Object right) does not do a left.equals(right) check. - Key: LANG-1081 URL: https://issues.apache.org/jira/browse/LANG-1081 Project: Commons Lang Issue Type: Bug Components: lang.builder.* Affects Versions: 3.3.2 Reporter: Jonathan Baker Priority: Trivial Attachments: DiffBuilder-equals_test_in_append_Objects.patch, DiffBuilderAppendsNonEqualObjects.java, DiffBuilderAppendsNonEqualObjectsFixed.java Original Estimate: 1m Remaining Estimate: 1m Only testing == without testing equals() seems wrong. Should an equals() test be added after determining that the parameters are not arrays? -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Commented] (CSV-147) Better error handling in CSV, see included code
[
https://issues.apache.org/jira/browse/CSV-147?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=14281722#comment-14281722
]
Benedikt Ritter commented on CSV-147:
-
Hello [~speterson],
I'll try to have a look at your patch next week.
regards,
Benedikt
Better error handling in CSV, see included code
---
Key: CSV-147
URL: https://issues.apache.org/jira/browse/CSV-147
Project: Commons CSV
Issue Type: Improvement
Components: Parser
Affects Versions: 1.1
Reporter: Steven Peterson
Labels: easyfix
Fix For: Discussion
Attachments: csv-exceptionsupport.patch
Original Estimate: 0.25h
Remaining Estimate: 0.25h
When parsing long files, and there is problem with parsing the data, it would
be very useful to know the exact data that is bad when an exception is
thrown. As CSVParser maintains a portion of the current record that was read
when an exception is thrown (in the 'record' property), can we make this
information public through something like this:
{code:java}
public String[] getLastRecordData() {
return this.record.toArray(new String[this.record.size()]);
}
{code}
With a method like this, it would be easy to pull in part of the data that
was in the faulty record after an exception was thrown, aiding in cleaning up
the data.
--
This message was sent by Atlassian JIRA
(v6.3.4#6332)
[jira] [Commented] (VALIDATOR-357) Upgrade BeanUtils
[ https://issues.apache.org/jira/browse/VALIDATOR-357?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=14281720#comment-14281720 ] Benedikt Ritter commented on VALIDATOR-357: --- If this is the only reference, we could probably remove the dependency at all. Shouldn't be too hard to implement the functionality in validator. Upgrade BeanUtils - Key: VALIDATOR-357 URL: https://issues.apache.org/jira/browse/VALIDATOR-357 Project: Commons Validator Issue Type: New Feature Components: Framework Affects Versions: 1.1.3 Release, 1.2.0 Release, 1.3.0 Release, 1.3.1 Release, 1.4.0 Release, 1.4.1 Release Reporter: David Dillard Priority: Minor Fix For: 1.5.0 Validator 1.41 depends on BeanUtils 1.8.3. This has a potential security issue, see http://commons.apache.org/proper/commons-beanutils/javadocs/v1.9.2/RELEASE-NOTES.txt Also, see http://www.cvedetails.com/cve-details.php?t=1cve_id=cve-2014-0114 Even if this issue doesn't affect Validator, BeanUtils should be upgraded so that issue issue doesn't affect other users of BeanUtils given the screwy way some builders (e.g. Maven) resolve conflicting dependencies. -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Resolved] (DBCP-423) PoolingDataSource should implement Closeable
[
https://issues.apache.org/jira/browse/DBCP-423?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Phil Steitz resolved DBCP-423.
--
Resolution: Fixed
Fix incorporating comments committed in r1652830.
A final comment on exception handling on close:
The current implementation of close in pool 2.x actually swallows and logs
exceptions generated by factory methods during clear(). That is where the
SQLExceptions discussed above would originate. DBCP has a
SwallowedExceptionListener that logs these. I hedged in the test cases -
allowing either swallow/log (current behavior of [pool]) or wrap / propagate
(unlikely to happen and effectively impossible to test with current impls).
PoolingDataSource should implement Closeable
Key: DBCP-423
URL: https://issues.apache.org/jira/browse/DBCP-423
Project: Commons Dbcp
Issue Type: Improvement
Affects Versions: 2.0
Reporter: Christian Schneider
Fix For: 2.1
Attachments: DBCP-423.patch
Currently PoolingDataSource only implements DataSource.
I have the following case in ops4j pax-jdbc. I offer a DataSourceFactory in
one bundle that can create a pooling DataSource.
Then in another bundle I create DataSources based on config in
ConfigurationAdmin. So when the config appears I create the DataSource, when
the config goes away I have to destroy it.
It is important to correctly dispose the DataSource as the pool has to be
closed. As I can not depend on dbcp in the bundle that destroys the
DataSource I currently have no simple way to destroy the DataSource.
This is where I create the DataSource:
https://github.com/ops4j/org.ops4j.pax.jdbc/blob/master/pax-jdbc-pool/src/main/java/org/ops4j/pax/jdbc/pool/impl/PooledDataSourceFactory.java
I was able to solve it by a kind of hack. I extended the PoolingDataSource
with a class that supports Closeable. So from the other bundle I could check
if the object implements Closeable and call close.
It would be a lot easier if PoolingDataSource would implement Closeable like
I did. The same is true for GenericObjectPool and the other pools. If they
would implement Closeable then handling them would be a lot easier.
They already support a close method so it would be a small change.
public class CloseablePoolingDataSourceC extends Connection extends
PoolingDataSourceC implements Closeable {
public CloseablePoolingDataSource(ObjectPoolC pool) {
super(pool);
}
@Override
public void close() throws IOException {
getPool().close();
}
}
--
This message was sent by Atlassian JIRA
(v6.3.4#6332)
[jira] [Commented] (VFS-558) java.lang.UnsupportedOperationException in FtpFileObject
[ https://issues.apache.org/jira/browse/VFS-558?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=14281876#comment-14281876 ] Bernd Eckenfels commented on VFS-558: - Thanks for the report, I agree with your analysis, we need to check that. BTW: I also think that the case of moving a file into an empty folder must be in the provider test suite. If you have some time, it would be best when you can start with exactly that reproducer. BTW2: do you use OnCallRefresher on purpose, I can imagine that makes FTP quite slow. java.lang.UnsupportedOperationException in FtpFileObject Key: VFS-558 URL: https://issues.apache.org/jira/browse/VFS-558 Project: Commons VFS Issue Type: Bug Affects Versions: 2.0 Reporter: L I am getting the following exception in my code: java.lang.UnsupportedOperationException at java.util.Collections$UnmodifiableMap.remove(Collections.java:1345) at org.apache.commons.vfs2.provider.ftp.FtpFileObject.onChildrenChanged(FtpFileObject.java:271) at org.apache.commons.vfs2.provider.AbstractFileObject.childrenChanged(AbstractFileObject.java:240) at org.apache.commons.vfs2.provider.AbstractFileObject.notifyParent(AbstractFileObject.java:1931) at org.apache.commons.vfs2.provider.AbstractFileObject.handleCreate(AbstractFileObject.java:1577) at org.apache.commons.vfs2.provider.AbstractFileObject.moveTo(AbstractFileObject.java:1866) at org.apache.commons.vfs2.impl.DecoratedFileObject.moveTo(DecoratedFileObject.java:241) at org.apache.commons.vfs2.cache.OnCallRefreshFileObject.moveTo(OnCallRefreshFileObject.java:184) ... I guess it is caused by the fact that children field is set to EMPTY_FTP_FILE_MAP at the moment onChildrenChanged() is invoked. I also do not like line 1866 in AbstractFileObject.java. To me it looks like it might be the real cause of the problem: FileObjectUtils.getAbstractFileObject(destFile).handleCreate(getType()); Must it not be destFile.getType()? But even if I am right about AbstractFileObject.java:1866, FtpFileObject.onChildrenChanged() must be corrected as well. -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Created] (COMPRESS-298) Cleaner way to catch/detect Seven7 files which are password protected
Nick Burch created COMPRESS-298:
---
Summary: Cleaner way to catch/detect Seven7 files which are
password protected
Key: COMPRESS-298
URL: https://issues.apache.org/jira/browse/COMPRESS-298
Project: Commons Compress
Issue Type: Improvement
Components: Archivers
Affects Versions: 1.8.1
Reporter: Nick Burch
Currently, if we open a password protected 7z file and call {{getNextEntry()}}
on it, it will blow up with an IOException with a specific string:
{code}
java.io.IOException: Cannot read encrypted files without a password
at
org.apache.commons.compress.archivers.sevenz.AES256SHA256Decoder$1.init(AES256SHA256Decoder.java:56)
at
org.apache.commons.compress.archivers.sevenz.AES256SHA256Decoder$1.read(AES256SHA256Decoder.java:112)
at java.io.DataInputStream.readUnsignedByte(DataInputStream.java:288)
at org.tukaani.xz.rangecoder.RangeDecoderFromStream.init(Unknown
Source)
at org.tukaani.xz.LZMAInputStream.initialize(Unknown Source)
at org.tukaani.xz.LZMAInputStream.initialize(Unknown Source)
at org.tukaani.xz.LZMAInputStream.init(Unknown Source)
at
org.apache.commons.compress.archivers.sevenz.Coders$LZMADecoder.decode(Coders.java:113)
at
org.apache.commons.compress.archivers.sevenz.Coders.addDecoder(Coders.java:77)
at
org.apache.commons.compress.archivers.sevenz.SevenZFile.buildDecoderStack(SevenZFile.java:853)
at
org.apache.commons.compress.archivers.sevenz.SevenZFile.buildDecodingStream(SevenZFile.java:820)
at
org.apache.commons.compress.archivers.sevenz.SevenZFile.getNextEntry(SevenZFile.java:151)
{code}
It would be good if either a specific subtype of IOException could be thrown
(which could then be caught to differentiate this from other kinds of IO
problems), or if a method could be added to SevenZFile which could be called to
see if a password is needed / given password is correct
(If implemented, this would help make the code in Tika dealing with 7z files
cleaner)
--
This message was sent by Atlassian JIRA
(v6.3.4#6332)
[jira] [Commented] (NET-525) Added missing set methods on NTP class and interface
[ https://issues.apache.org/jira/browse/NET-525?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=14282000#comment-14282000 ] Sebb commented on NET-525: -- It now appears that adding a method to an interface does not break binary compatibility [1]. Unfortunately Clirr does not distinguish between source and binary compat. in the generated report. URL: http://svn.apache.org/r1652868 Log: revert r1652867 Removed: commons/proper/net/trunk/src/main/java/org/apache/commons/net/ntp/NtpV3Packetbis.java Modified: commons/proper/net/trunk/src/main/java/examples/ntp/SimpleNTPServer.java commons/proper/net/trunk/src/main/java/org/apache/commons/net/ntp/NtpV3Impl.java commons/proper/net/trunk/src/main/java/org/apache/commons/net/ntp/NtpV3Packet.java commons/proper/net/trunk/src/test/java/org/apache/commons/net/ntp/TestNtpPacket.java commons/proper/net/trunk/src/test/java/org/apache/commons/net/ntp/TestTimeInfo.java [1] https://docs.oracle.com/javase/specs/jls/se5.0/html/binaryComp.html#45348 Added missing set methods on NTP class and interface Key: NET-525 URL: https://issues.apache.org/jira/browse/NET-525 Project: Commons Net Issue Type: Improvement Affects Versions: 3.3 Reporter: jason mathews Labels: ntp Fix For: 3.4 Attachments: diff.patch.txt I was the original contributor of the NTP implementation and have recently cleaned the source and submitting the relevant changes. Here is the summary of changes: src/main/java/org/apache/commons/net/ntp/TimeInfo.java -Added missing equals() and hashCode() methods -Added new method: getAddress() src/main/java/org/apache/commons/net/ntp/NtpV3Packet.java -Added missing methods: setPrecision(), setRootDelay(), and setRootDispersion() src/main/java/org/apache/commons/net/ntp/NtpV3Impl.java -Added missing equals() and hashCode() methods -Added missing set methods: setRootDelay(), setRootDispersion(), -Added validation check to setDatagramPacket() Added additional tests: -src/test/java/org/apache/commons/net/ntp/TestNtpPacket.java -src/test/java/org/apache/commons/net/ntp/TestTimeInfo.java See attached patch. -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Resolved] (VFS-558) java.lang.UnsupportedOperationException in FtpFileObject
[ https://issues.apache.org/jira/browse/VFS-558?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Bernd Eckenfels resolved VFS-558. - Resolution: Fixed Fix Version/s: 2.1 Assignee: Bernd Eckenfels I just added a test case, but it does only produce the problem when ON_CALL is used. Because otherwise the getType() on the source will not re-check the renamed file and uses the correct type. BTW: a lot of the test cases fail with ON_CALL (mostly because they use assertSame() to verify exepcted results. We will have to change that and then think about running the provider tests with all strategies. Maybe even with a NullFilesCache.) Anyway, I fixed the rename in trunk, can you try? (and really consider not using ON_CALL :) http://svn.apache.org/r1652870 java.lang.UnsupportedOperationException in FtpFileObject Key: VFS-558 URL: https://issues.apache.org/jira/browse/VFS-558 Project: Commons VFS Issue Type: Bug Affects Versions: 2.0 Reporter: L Assignee: Bernd Eckenfels Fix For: 2.1 I am getting the following exception in my code: java.lang.UnsupportedOperationException at java.util.Collections$UnmodifiableMap.remove(Collections.java:1345) at org.apache.commons.vfs2.provider.ftp.FtpFileObject.onChildrenChanged(FtpFileObject.java:271) at org.apache.commons.vfs2.provider.AbstractFileObject.childrenChanged(AbstractFileObject.java:240) at org.apache.commons.vfs2.provider.AbstractFileObject.notifyParent(AbstractFileObject.java:1931) at org.apache.commons.vfs2.provider.AbstractFileObject.handleCreate(AbstractFileObject.java:1577) at org.apache.commons.vfs2.provider.AbstractFileObject.moveTo(AbstractFileObject.java:1866) at org.apache.commons.vfs2.impl.DecoratedFileObject.moveTo(DecoratedFileObject.java:241) at org.apache.commons.vfs2.cache.OnCallRefreshFileObject.moveTo(OnCallRefreshFileObject.java:184) ... I guess it is caused by the fact that children field is set to EMPTY_FTP_FILE_MAP at the moment onChildrenChanged() is invoked. I also do not like line 1866 in AbstractFileObject.java. To me it looks like it might be the real cause of the problem: FileObjectUtils.getAbstractFileObject(destFile).handleCreate(getType()); Must it not be destFile.getType()? But even if I am right about AbstractFileObject.java:1866, FtpFileObject.onChildrenChanged() must be corrected as well. -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Resolved] (VFS-557) [webdav][test] leaves undeleted temp directories around
[
https://issues.apache.org/jira/browse/VFS-557?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Bernd Eckenfels resolved VFS-557.
-
Resolution: Fixed
Fix Version/s: 2.1
The directories are not written under core/target/test/ and properly deleted. I
also removed the core/jackrabbit/tmp/ directory which was created by an unused
jackrabbit servlet. Commited with r1652881.
The directory can be preserved when specifying
-DWebdavProviderTestCase.Debug=true (to read the logfiles).
[webdav][test] leaves undeleted temp directories around
---
Key: VFS-557
URL: https://issues.apache.org/jira/browse/VFS-557
Project: Commons VFS
Issue Type: Bug
Affects Versions: 2.1
Environment: Win7 x64, Oracle Java 7+8
Reporter: Bernd Eckenfels
Assignee: Bernd Eckenfels
Labels: test,
Fix For: 2.1
When testing the webdav provider with the built-in JCR jackrabbit repository
there is a number of Webdav temp directories left around under windows. When
you enable debug logging, you can see that it failed to delete them. What you
can see are active jackrabit and jetty logfiles.
The reason for them is, that the JCL Appenders do not get removed/closed on
shutdown.
(I also wonder why this is outside the target/ directory).
{code}12.01.2015 05:18DIR
WebdavProviderTestCase_925481737317534284825743295675598
09.01.2015 00:04DIR
WebdavProviderTestCase_98639382858475597547744387200330
11.01.2015 16:01DIR
WebdavsProviderTestCase_1002200317504082633777911798076546
1
{code}
--
This message was sent by Atlassian JIRA
(v6.3.4#6332)
[jira] [Commented] (DBCP-427) Examines 'SQLException's thrown by underlying connections or statements for fatal (disconnection) errors
[
https://issues.apache.org/jira/browse/DBCP-427?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=14281978#comment-14281978
]
Phil Steitz commented on DBCP-427:
--
Why not just adapt the BDS invalidateConnection code to immediately invalidate
/ remove a connection that throws a fatal connection exception. So instead of
{code}
protected void handleException(SQLException e) throws SQLException {
fatalSqlExceptionThrown |= Utils.isDisconnectionSqlException(e);
super.handleException(e);
}
{code}
we just do
{code}
protected void handleException(SQLException e) throws SQLException {
if (Utils.isDisconnectionSqlException(e)) {
invalidate();
}
super.handleException(e);
{code}
where invalidate() does what BDS#invalidateConnection does - attempt to close
and then remove from the pool.
Examines 'SQLException's thrown by underlying connections or statements for
fatal (disconnection) errors
Key: DBCP-427
URL: https://issues.apache.org/jira/browse/DBCP-427
Project: Commons Dbcp
Issue Type: Improvement
Affects Versions: 2.0
Reporter: Vladimir Konkov
Priority: Minor
Fix For: 2.1
Attachments: DBCP-427_initial_impl.diff
Affected cases:
1. Ability to detect severed connection without need for validity check (it
can be time demand).
2. Not all fatal errors detected with simple validation query or isValid()
call. For example:
Broken XA connections of MS SQL Server and Oracle Database (and may be other)
pass validation for both isValid() and simple validation query such as 'SELEC
1 FROM DUAL' but throw fatal errors on data and/or transaction manipulation
calls. Such errors gone only after reconnect. In case of use DBCP for polling
application has no chance to cleanup broken connection.
By providing infractructure for check thrown exceptions and mark
PoolableConnection as poisoned we can cleanup pool on validation phase.
--
This message was sent by Atlassian JIRA
(v6.3.4#6332)
[jira] [Comment Edited] (DBCP-427) Examines 'SQLException's thrown by underlying connections or statements for fatal (disconnection) errors
[
https://issues.apache.org/jira/browse/DBCP-427?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=14281978#comment-14281978
]
Phil Steitz edited comment on DBCP-427 at 1/18/15 9:56 PM:
---
Why not just adapt the BDS invalidateConnection code to immediately invalidate
/ remove a connection that throws a fatal connection exception. So instead of
{code}
protected void handleException(SQLException e) throws SQLException {
fatalSqlExceptionThrown |= Utils.isDisconnectionSqlException(e);
super.handleException(e);
}
{code}
we just do
{code}
protected void handleException(SQLException e) throws SQLException {
if (Utils.isDisconnectionSqlException(e)) {
invalidate();
}
super.handleException(e);
}
{code}
where invalidate() does what BDS#invalidateConnection does - attempt to close
and then remove from the pool.
was (Author: psteitz):
Why not just adapt the BDS invalidateConnection code to immediately invalidate
/ remove a connection that throws a fatal connection exception. So instead of
{code}
protected void handleException(SQLException e) throws SQLException {
fatalSqlExceptionThrown |= Utils.isDisconnectionSqlException(e);
super.handleException(e);
}
{code}
we just do
{code}
protected void handleException(SQLException e) throws SQLException {
if (Utils.isDisconnectionSqlException(e)) {
invalidate();
}
super.handleException(e);
{code}
where invalidate() does what BDS#invalidateConnection does - attempt to close
and then remove from the pool.
Examines 'SQLException's thrown by underlying connections or statements for
fatal (disconnection) errors
Key: DBCP-427
URL: https://issues.apache.org/jira/browse/DBCP-427
Project: Commons Dbcp
Issue Type: Improvement
Affects Versions: 2.0
Reporter: Vladimir Konkov
Priority: Minor
Fix For: 2.1
Attachments: DBCP-427_initial_impl.diff
Affected cases:
1. Ability to detect severed connection without need for validity check (it
can be time demand).
2. Not all fatal errors detected with simple validation query or isValid()
call. For example:
Broken XA connections of MS SQL Server and Oracle Database (and may be other)
pass validation for both isValid() and simple validation query such as 'SELEC
1 FROM DUAL' but throw fatal errors on data and/or transaction manipulation
calls. Such errors gone only after reconnect. In case of use DBCP for polling
application has no chance to cleanup broken connection.
By providing infractructure for check thrown exceptions and mark
PoolableConnection as poisoned we can cleanup pool on validation phase.
--
This message was sent by Atlassian JIRA
(v6.3.4#6332)
[jira] [Commented] (NET-525) Added missing set methods on NTP class and interface
[ https://issues.apache.org/jira/browse/NET-525?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=14281991#comment-14281991 ] Sebb commented on NET-525: -- Changes to interface broke compatibility. URL: http://svn.apache.org/r1652867 Log: NET-525 Added missing set methods on NTP class and interface Restore compatibility Added: commons/proper/net/trunk/src/main/java/org/apache/commons/net/ntp/NtpV3Packetbis.java Modified: commons/proper/net/trunk/src/main/java/examples/ntp/SimpleNTPServer.java commons/proper/net/trunk/src/main/java/org/apache/commons/net/ntp/NtpV3Impl.java commons/proper/net/trunk/src/main/java/org/apache/commons/net/ntp/NtpV3Packet.java commons/proper/net/trunk/src/test/java/org/apache/commons/net/ntp/TestNtpPacket.java commons/proper/net/trunk/src/test/java/org/apache/commons/net/ntp/TestTimeInfo.java Added missing set methods on NTP class and interface Key: NET-525 URL: https://issues.apache.org/jira/browse/NET-525 Project: Commons Net Issue Type: Improvement Affects Versions: 3.3 Reporter: jason mathews Labels: ntp Fix For: 3.4 Attachments: diff.patch.txt I was the original contributor of the NTP implementation and have recently cleaned the source and submitting the relevant changes. Here is the summary of changes: src/main/java/org/apache/commons/net/ntp/TimeInfo.java -Added missing equals() and hashCode() methods -Added new method: getAddress() src/main/java/org/apache/commons/net/ntp/NtpV3Packet.java -Added missing methods: setPrecision(), setRootDelay(), and setRootDispersion() src/main/java/org/apache/commons/net/ntp/NtpV3Impl.java -Added missing equals() and hashCode() methods -Added missing set methods: setRootDelay(), setRootDispersion(), -Added validation check to setDatagramPacket() Added additional tests: -src/test/java/org/apache/commons/net/ntp/TestNtpPacket.java -src/test/java/org/apache/commons/net/ntp/TestTimeInfo.java See attached patch. -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Issue Comment Deleted] (DBCP-427) Examines 'SQLException's thrown by underlying connections or statements for fatal (disconnection) errors
[
https://issues.apache.org/jira/browse/DBCP-427?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Phil Steitz updated DBCP-427:
-
Comment: was deleted
(was: Why not just adapt the BDS invalidateConnection code to immediately
invalidate / remove a connection that throws a fatal connection exception. So
instead of
{code}
protected void handleException(SQLException e) throws SQLException {
fatalSqlExceptionThrown |= Utils.isDisconnectionSqlException(e);
super.handleException(e);
}
{code}
we just do
{code}
protected void handleException(SQLException e) throws SQLException {
if (Utils.isDisconnectionSqlException(e)) {
invalidate();
}
super.handleException(e);
}
{code}
where invalidate() does what BDS#invalidateConnection does - attempt to close
and then remove from the pool.
)
Examines 'SQLException's thrown by underlying connections or statements for
fatal (disconnection) errors
Key: DBCP-427
URL: https://issues.apache.org/jira/browse/DBCP-427
Project: Commons Dbcp
Issue Type: Improvement
Affects Versions: 2.0
Reporter: Vladimir Konkov
Priority: Minor
Fix For: 2.1
Attachments: DBCP-427_initial_impl.diff
Affected cases:
1. Ability to detect severed connection without need for validity check (it
can be time demand).
2. Not all fatal errors detected with simple validation query or isValid()
call. For example:
Broken XA connections of MS SQL Server and Oracle Database (and may be other)
pass validation for both isValid() and simple validation query such as 'SELEC
1 FROM DUAL' but throw fatal errors on data and/or transaction manipulation
calls. Such errors gone only after reconnect. In case of use DBCP for polling
application has no chance to cleanup broken connection.
By providing infractructure for check thrown exceptions and mark
PoolableConnection as poisoned we can cleanup pool on validation phase.
--
This message was sent by Atlassian JIRA
(v6.3.4#6332)
[jira] [Commented] (VFS-558) java.lang.UnsupportedOperationException in FtpFileObject
[ https://issues.apache.org/jira/browse/VFS-558?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=14281955#comment-14281955 ] Bernd Eckenfels commented on VFS-558: - I would use ON_RESOLVE or even MANUAL and then use refresh() in those particular places where you want to have an up-to-date view of the children. Because with ON_CALL you cannot control which of the methods actually need the refresh and which not. But: this should not be related to your bug report, I just noticed it. java.lang.UnsupportedOperationException in FtpFileObject Key: VFS-558 URL: https://issues.apache.org/jira/browse/VFS-558 Project: Commons VFS Issue Type: Bug Affects Versions: 2.0 Reporter: L I am getting the following exception in my code: java.lang.UnsupportedOperationException at java.util.Collections$UnmodifiableMap.remove(Collections.java:1345) at org.apache.commons.vfs2.provider.ftp.FtpFileObject.onChildrenChanged(FtpFileObject.java:271) at org.apache.commons.vfs2.provider.AbstractFileObject.childrenChanged(AbstractFileObject.java:240) at org.apache.commons.vfs2.provider.AbstractFileObject.notifyParent(AbstractFileObject.java:1931) at org.apache.commons.vfs2.provider.AbstractFileObject.handleCreate(AbstractFileObject.java:1577) at org.apache.commons.vfs2.provider.AbstractFileObject.moveTo(AbstractFileObject.java:1866) at org.apache.commons.vfs2.impl.DecoratedFileObject.moveTo(DecoratedFileObject.java:241) at org.apache.commons.vfs2.cache.OnCallRefreshFileObject.moveTo(OnCallRefreshFileObject.java:184) ... I guess it is caused by the fact that children field is set to EMPTY_FTP_FILE_MAP at the moment onChildrenChanged() is invoked. I also do not like line 1866 in AbstractFileObject.java. To me it looks like it might be the real cause of the problem: FileObjectUtils.getAbstractFileObject(destFile).handleCreate(getType()); Must it not be destFile.getType()? But even if I am right about AbstractFileObject.java:1866, FtpFileObject.onChildrenChanged() must be corrected as well. -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Comment Edited] (VFS-558) java.lang.UnsupportedOperationException in FtpFileObject
[ https://issues.apache.org/jira/browse/VFS-558?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=14281942#comment-14281942 ] L edited comment on VFS-558 at 1/18/15 8:18 PM: Re: BTW2: do you use OnCallRefresher on purpose, I can imagine that makes FTP quite slow. Well, I do use CacheStrategy.ON_CALL, so yes, it is OnCallRefreshFileObject. My code has some checks before performing moveTo to verify the destination file is not there so I am not overwriting it. My tests gave me quite a lot of spurious warnings saying the file IS there before the rename while I quite sure it was not there. Adding the CacheStrategy.ON_CALL helped a lot but sometimes I still get false positives. was (Author: klv_m72): Re: BTW2: do you use OnCallRefresher on purpose, I can imagine that makes FTP quite slow. Well, I do use CacheStrategy.ON_CALL, so yes, it is OnCallRefreshFileObject. My code has some checks before performing moveTo to verify the destination file is not there so I am not overwriting it. My tests gave me quite a lot of spurious warnings saying the file IS there before the rename while I quite sure it was not there. Adding the CacheStrategy.ON_CALL helped a lot but sometimes I still get resulted in most of the false positive java.lang.UnsupportedOperationException in FtpFileObject Key: VFS-558 URL: https://issues.apache.org/jira/browse/VFS-558 Project: Commons VFS Issue Type: Bug Affects Versions: 2.0 Reporter: L I am getting the following exception in my code: java.lang.UnsupportedOperationException at java.util.Collections$UnmodifiableMap.remove(Collections.java:1345) at org.apache.commons.vfs2.provider.ftp.FtpFileObject.onChildrenChanged(FtpFileObject.java:271) at org.apache.commons.vfs2.provider.AbstractFileObject.childrenChanged(AbstractFileObject.java:240) at org.apache.commons.vfs2.provider.AbstractFileObject.notifyParent(AbstractFileObject.java:1931) at org.apache.commons.vfs2.provider.AbstractFileObject.handleCreate(AbstractFileObject.java:1577) at org.apache.commons.vfs2.provider.AbstractFileObject.moveTo(AbstractFileObject.java:1866) at org.apache.commons.vfs2.impl.DecoratedFileObject.moveTo(DecoratedFileObject.java:241) at org.apache.commons.vfs2.cache.OnCallRefreshFileObject.moveTo(OnCallRefreshFileObject.java:184) ... I guess it is caused by the fact that children field is set to EMPTY_FTP_FILE_MAP at the moment onChildrenChanged() is invoked. I also do not like line 1866 in AbstractFileObject.java. To me it looks like it might be the real cause of the problem: FileObjectUtils.getAbstractFileObject(destFile).handleCreate(getType()); Must it not be destFile.getType()? But even if I am right about AbstractFileObject.java:1866, FtpFileObject.onChildrenChanged() must be corrected as well. -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Commented] (VFS-558) java.lang.UnsupportedOperationException in FtpFileObject
[ https://issues.apache.org/jira/browse/VFS-558?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=14281944#comment-14281944 ] L commented on VFS-558: --- Re: BTW2: do you use OnCallRefresher on purpose, I can imagine that makes FTP quite slow. Well, I do use CacheStrategy.ON_CALL, so yes, it is OnCallRefreshFileObject. My code has some checks before performing moveTo to verify the destination file is not there so I am not overwriting it. My tests gave me quite a lot of spurious warnings saying the file IS there before the rename while I quite sure it was not there. Adding the CacheStrategy.ON_CALL helped a lot but sometimes I still get resulted in most of the false positive java.lang.UnsupportedOperationException in FtpFileObject Key: VFS-558 URL: https://issues.apache.org/jira/browse/VFS-558 Project: Commons VFS Issue Type: Bug Affects Versions: 2.0 Reporter: L I am getting the following exception in my code: java.lang.UnsupportedOperationException at java.util.Collections$UnmodifiableMap.remove(Collections.java:1345) at org.apache.commons.vfs2.provider.ftp.FtpFileObject.onChildrenChanged(FtpFileObject.java:271) at org.apache.commons.vfs2.provider.AbstractFileObject.childrenChanged(AbstractFileObject.java:240) at org.apache.commons.vfs2.provider.AbstractFileObject.notifyParent(AbstractFileObject.java:1931) at org.apache.commons.vfs2.provider.AbstractFileObject.handleCreate(AbstractFileObject.java:1577) at org.apache.commons.vfs2.provider.AbstractFileObject.moveTo(AbstractFileObject.java:1866) at org.apache.commons.vfs2.impl.DecoratedFileObject.moveTo(DecoratedFileObject.java:241) at org.apache.commons.vfs2.cache.OnCallRefreshFileObject.moveTo(OnCallRefreshFileObject.java:184) ... I guess it is caused by the fact that children field is set to EMPTY_FTP_FILE_MAP at the moment onChildrenChanged() is invoked. I also do not like line 1866 in AbstractFileObject.java. To me it looks like it might be the real cause of the problem: FileObjectUtils.getAbstractFileObject(destFile).handleCreate(getType()); Must it not be destFile.getType()? But even if I am right about AbstractFileObject.java:1866, FtpFileObject.onChildrenChanged() must be corrected as well. -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Issue Comment Deleted] (VFS-558) java.lang.UnsupportedOperationException in FtpFileObject
[ https://issues.apache.org/jira/browse/VFS-558?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] L updated VFS-558: -- Comment: was deleted (was: Re: BTW2: do you use OnCallRefresher on purpose, I can imagine that makes FTP quite slow. Well, I do use CacheStrategy.ON_CALL, so yes, it is OnCallRefreshFileObject. My code has some checks before performing moveTo to verify the destination file is not there so I am not overwriting it. My tests gave me quite a lot of spurious warnings saying the file IS there before the rename while I quite sure it was not there. Adding the CacheStrategy.ON_CALL helped a lot but sometimes I still get resulted in most of the false positive ) java.lang.UnsupportedOperationException in FtpFileObject Key: VFS-558 URL: https://issues.apache.org/jira/browse/VFS-558 Project: Commons VFS Issue Type: Bug Affects Versions: 2.0 Reporter: L I am getting the following exception in my code: java.lang.UnsupportedOperationException at java.util.Collections$UnmodifiableMap.remove(Collections.java:1345) at org.apache.commons.vfs2.provider.ftp.FtpFileObject.onChildrenChanged(FtpFileObject.java:271) at org.apache.commons.vfs2.provider.AbstractFileObject.childrenChanged(AbstractFileObject.java:240) at org.apache.commons.vfs2.provider.AbstractFileObject.notifyParent(AbstractFileObject.java:1931) at org.apache.commons.vfs2.provider.AbstractFileObject.handleCreate(AbstractFileObject.java:1577) at org.apache.commons.vfs2.provider.AbstractFileObject.moveTo(AbstractFileObject.java:1866) at org.apache.commons.vfs2.impl.DecoratedFileObject.moveTo(DecoratedFileObject.java:241) at org.apache.commons.vfs2.cache.OnCallRefreshFileObject.moveTo(OnCallRefreshFileObject.java:184) ... I guess it is caused by the fact that children field is set to EMPTY_FTP_FILE_MAP at the moment onChildrenChanged() is invoked. I also do not like line 1866 in AbstractFileObject.java. To me it looks like it might be the real cause of the problem: FileObjectUtils.getAbstractFileObject(destFile).handleCreate(getType()); Must it not be destFile.getType()? But even if I am right about AbstractFileObject.java:1866, FtpFileObject.onChildrenChanged() must be corrected as well. -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Commented] (VFS-558) java.lang.UnsupportedOperationException in FtpFileObject
[ https://issues.apache.org/jira/browse/VFS-558?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=14281943#comment-14281943 ] L commented on VFS-558: --- Re: BTW2: do you use OnCallRefresher on purpose, I can imagine that makes FTP quite slow. Well, I do use CacheStrategy.ON_CALL, so yes, it is OnCallRefreshFileObject. My code has some checks before performing moveTo to verify the destination file is not there so I am not overwriting it. My tests gave me quite a lot of spurious warnings saying the file IS there before the rename while I quite sure it was not there. Adding the CacheStrategy.ON_CALL helped a lot but sometimes I still get resulted in most of the false positive java.lang.UnsupportedOperationException in FtpFileObject Key: VFS-558 URL: https://issues.apache.org/jira/browse/VFS-558 Project: Commons VFS Issue Type: Bug Affects Versions: 2.0 Reporter: L I am getting the following exception in my code: java.lang.UnsupportedOperationException at java.util.Collections$UnmodifiableMap.remove(Collections.java:1345) at org.apache.commons.vfs2.provider.ftp.FtpFileObject.onChildrenChanged(FtpFileObject.java:271) at org.apache.commons.vfs2.provider.AbstractFileObject.childrenChanged(AbstractFileObject.java:240) at org.apache.commons.vfs2.provider.AbstractFileObject.notifyParent(AbstractFileObject.java:1931) at org.apache.commons.vfs2.provider.AbstractFileObject.handleCreate(AbstractFileObject.java:1577) at org.apache.commons.vfs2.provider.AbstractFileObject.moveTo(AbstractFileObject.java:1866) at org.apache.commons.vfs2.impl.DecoratedFileObject.moveTo(DecoratedFileObject.java:241) at org.apache.commons.vfs2.cache.OnCallRefreshFileObject.moveTo(OnCallRefreshFileObject.java:184) ... I guess it is caused by the fact that children field is set to EMPTY_FTP_FILE_MAP at the moment onChildrenChanged() is invoked. I also do not like line 1866 in AbstractFileObject.java. To me it looks like it might be the real cause of the problem: FileObjectUtils.getAbstractFileObject(destFile).handleCreate(getType()); Must it not be destFile.getType()? But even if I am right about AbstractFileObject.java:1866, FtpFileObject.onChildrenChanged() must be corrected as well. -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Issue Comment Deleted] (VFS-558) java.lang.UnsupportedOperationException in FtpFileObject
[ https://issues.apache.org/jira/browse/VFS-558?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] L updated VFS-558: -- Comment: was deleted (was: Re: BTW2: do you use OnCallRefresher on purpose, I can imagine that makes FTP quite slow. Well, I do use CacheStrategy.ON_CALL, so yes, it is OnCallRefreshFileObject. My code has some checks before performing moveTo to verify the destination file is not there so I am not overwriting it. My tests gave me quite a lot of spurious warnings saying the file IS there before the rename while I quite sure it was not there. Adding the CacheStrategy.ON_CALL helped a lot but sometimes I still get resulted in most of the false positive ) java.lang.UnsupportedOperationException in FtpFileObject Key: VFS-558 URL: https://issues.apache.org/jira/browse/VFS-558 Project: Commons VFS Issue Type: Bug Affects Versions: 2.0 Reporter: L I am getting the following exception in my code: java.lang.UnsupportedOperationException at java.util.Collections$UnmodifiableMap.remove(Collections.java:1345) at org.apache.commons.vfs2.provider.ftp.FtpFileObject.onChildrenChanged(FtpFileObject.java:271) at org.apache.commons.vfs2.provider.AbstractFileObject.childrenChanged(AbstractFileObject.java:240) at org.apache.commons.vfs2.provider.AbstractFileObject.notifyParent(AbstractFileObject.java:1931) at org.apache.commons.vfs2.provider.AbstractFileObject.handleCreate(AbstractFileObject.java:1577) at org.apache.commons.vfs2.provider.AbstractFileObject.moveTo(AbstractFileObject.java:1866) at org.apache.commons.vfs2.impl.DecoratedFileObject.moveTo(DecoratedFileObject.java:241) at org.apache.commons.vfs2.cache.OnCallRefreshFileObject.moveTo(OnCallRefreshFileObject.java:184) ... I guess it is caused by the fact that children field is set to EMPTY_FTP_FILE_MAP at the moment onChildrenChanged() is invoked. I also do not like line 1866 in AbstractFileObject.java. To me it looks like it might be the real cause of the problem: FileObjectUtils.getAbstractFileObject(destFile).handleCreate(getType()); Must it not be destFile.getType()? But even if I am right about AbstractFileObject.java:1866, FtpFileObject.onChildrenChanged() must be corrected as well. -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Commented] (VFS-558) java.lang.UnsupportedOperationException in FtpFileObject
[ https://issues.apache.org/jira/browse/VFS-558?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=14281942#comment-14281942 ] L commented on VFS-558: --- Re: BTW2: do you use OnCallRefresher on purpose, I can imagine that makes FTP quite slow. Well, I do use CacheStrategy.ON_CALL, so yes, it is OnCallRefreshFileObject. My code has some checks before performing moveTo to verify the destination file is not there so I am not overwriting it. My tests gave me quite a lot of spurious warnings saying the file IS there before the rename while I quite sure it was not there. Adding the CacheStrategy.ON_CALL helped a lot but sometimes I still get resulted in most of the false positive java.lang.UnsupportedOperationException in FtpFileObject Key: VFS-558 URL: https://issues.apache.org/jira/browse/VFS-558 Project: Commons VFS Issue Type: Bug Affects Versions: 2.0 Reporter: L I am getting the following exception in my code: java.lang.UnsupportedOperationException at java.util.Collections$UnmodifiableMap.remove(Collections.java:1345) at org.apache.commons.vfs2.provider.ftp.FtpFileObject.onChildrenChanged(FtpFileObject.java:271) at org.apache.commons.vfs2.provider.AbstractFileObject.childrenChanged(AbstractFileObject.java:240) at org.apache.commons.vfs2.provider.AbstractFileObject.notifyParent(AbstractFileObject.java:1931) at org.apache.commons.vfs2.provider.AbstractFileObject.handleCreate(AbstractFileObject.java:1577) at org.apache.commons.vfs2.provider.AbstractFileObject.moveTo(AbstractFileObject.java:1866) at org.apache.commons.vfs2.impl.DecoratedFileObject.moveTo(DecoratedFileObject.java:241) at org.apache.commons.vfs2.cache.OnCallRefreshFileObject.moveTo(OnCallRefreshFileObject.java:184) ... I guess it is caused by the fact that children field is set to EMPTY_FTP_FILE_MAP at the moment onChildrenChanged() is invoked. I also do not like line 1866 in AbstractFileObject.java. To me it looks like it might be the real cause of the problem: FileObjectUtils.getAbstractFileObject(destFile).handleCreate(getType()); Must it not be destFile.getType()? But even if I am right about AbstractFileObject.java:1866, FtpFileObject.onChildrenChanged() must be corrected as well. -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Commented] (VFS-558) java.lang.UnsupportedOperationException in FtpFileObject
[ https://issues.apache.org/jira/browse/VFS-558?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=14281954#comment-14281954 ] Bernd Eckenfels commented on VFS-558: - Hm, what version of VFS you are using? 2.0 has only 1855 lines in AbstractFileObject and 2.1 (trunk) does not align with the line numbers. Do you maybe have an older trunk version? Can you try a newer trunk version? java.lang.UnsupportedOperationException in FtpFileObject Key: VFS-558 URL: https://issues.apache.org/jira/browse/VFS-558 Project: Commons VFS Issue Type: Bug Affects Versions: 2.0 Reporter: L I am getting the following exception in my code: java.lang.UnsupportedOperationException at java.util.Collections$UnmodifiableMap.remove(Collections.java:1345) at org.apache.commons.vfs2.provider.ftp.FtpFileObject.onChildrenChanged(FtpFileObject.java:271) at org.apache.commons.vfs2.provider.AbstractFileObject.childrenChanged(AbstractFileObject.java:240) at org.apache.commons.vfs2.provider.AbstractFileObject.notifyParent(AbstractFileObject.java:1931) at org.apache.commons.vfs2.provider.AbstractFileObject.handleCreate(AbstractFileObject.java:1577) at org.apache.commons.vfs2.provider.AbstractFileObject.moveTo(AbstractFileObject.java:1866) at org.apache.commons.vfs2.impl.DecoratedFileObject.moveTo(DecoratedFileObject.java:241) at org.apache.commons.vfs2.cache.OnCallRefreshFileObject.moveTo(OnCallRefreshFileObject.java:184) ... I guess it is caused by the fact that children field is set to EMPTY_FTP_FILE_MAP at the moment onChildrenChanged() is invoked. I also do not like line 1866 in AbstractFileObject.java. To me it looks like it might be the real cause of the problem: FileObjectUtils.getAbstractFileObject(destFile).handleCreate(getType()); Must it not be destFile.getType()? But even if I am right about AbstractFileObject.java:1866, FtpFileObject.onChildrenChanged() must be corrected as well. -- This message was sent by Atlassian JIRA (v6.3.4#6332)
