[jira] [Resolved] (DBCP-395) Please help.. Oracle connection problems.. Is it over connected or stucked?
[ https://issues.apache.org/jira/browse/DBCP-395?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Mark Thomas resolved DBCP-395. -- Resolution: Invalid Jira is not a support forum. Please use the users mailing list. Please help.. Oracle connection problems.. Is it over connected or stucked? --- Key: DBCP-395 URL: https://issues.apache.org/jira/browse/DBCP-395 Project: Commons Dbcp Issue Type: Bug Affects Versions: 1.2.1 Environment: OS : Ubuntu 11.10 JDK : 1.6 Database : Oracle 10g JDBC Driver : oracle jdbc driver type 4 DB Commits per secs : 600 Reporter: steve lee Attachments: epmailer.out_ We had ran email sendding system over 10 years. Recently we had oracle connection problem. We have 8 servers and all servers had same problem. My system's thread dump is following. I appreciate any helps. Thanks. ... Thread-6293 daemon prio=10 tid=0x7f65cc35e800 nid=0x637c waiting for monitor entry [0x7f65c6e3b000] java.lang.Thread.State: BLOCKED (on object monitor) at ep.server.epmailer.util.EPPoolingDataSource.getConnection(EPPoolingDataSource.java:72) - waiting to lock 0xfb430c20 (a java.lang.Class for ep.server.epmailer.util.EPPoolingDataSource) at ep.server.epmailer.EPMailSenderThread.checkOtherMailerStatus(EPMailSenderThread.java:2799) at ep.server.epmailer.EPMailSenderThread.run(EPMailSenderThread.java:438) at java.lang.Thread.run(Thread.java:662) Thread-6292 daemon prio=10 tid=0x7f65cc35d800 nid=0x637b waiting for monitor entry [0x7f65beab4000] java.lang.Thread.State: BLOCKED (on object monitor) at ep.server.epmailer.util.EPPoolingDataSource.getConnection(EPPoolingDataSource.java:72) - waiting to lock 0xfb430c20 (a java.lang.Class for ep.server.epmailer.util.EPPoolingDataSource) at ep.server.epmailer.EPMailSenderThread.updateSuccessMail(EPMailSenderThread.java:2597) at ep.server.epmailer.EPMailSenderThread.run(EPMailSenderThread.java:330) at java.lang.Thread.run(Thread.java:662) Thread-6291 daemon prio=10 tid=0x7f65cc80c000 nid=0x6377 runnable [0x7f65beaf4000] java.lang.Thread.State: RUNNABLE at java.net.SocketInputStream.socketRead0(Native Method) at java.net.SocketInputStream.read(SocketInputStream.java:129) at oracle.net.ns.Packet.receive(Unknown Source) at oracle.net.ns.NSProtocol.connect(Unknown Source) at oracle.jdbc.driver.T4CConnection.connect(T4CConnection.java:844) at oracle.jdbc.driver.T4CConnection.logon(T4CConnection.java:268) at oracle.jdbc.driver.PhysicalConnection.init(PhysicalConnection.java:414) at oracle.jdbc.driver.T4CConnection.init(T4CConnection.java:165) at oracle.jdbc.driver.T4CDriverExtension.getConnection(T4CDriverExtension.java:35) at oracle.jdbc.driver.OracleDriver.connect(OracleDriver.java:801) at java.sql.DriverManager.getConnection(DriverManager.java:582) at java.sql.DriverManager.getConnection(DriverManager.java:185) at org.apache.commons.dbcp.DriverManagerConnectionFactory.createConnection(DriverManagerConnectionFactory.java:48) at org.apache.commons.dbcp.PoolableConnectionFactory.makeObject(PoolableConnectionFactory.java:290) - locked 0xc231e9a8 (a org.apache.commons.dbcp.PoolableConnectionFactory) at org.apache.commons.pool.impl.GenericObjectPool.borrowObject(GenericObjectPool.java:771) at org.apache.commons.dbcp.PoolingDataSource.getConnection(PoolingDataSource.java:95) at ep.server.epmailer.util.EPPoolingDataSource.getConnection(EPPoolingDataSource.java:75) - locked 0xfb430c20 (a java.lang.Class for ep.server.epmailer.util.EPPoolingDataSource) at ep.server.epmailer.EPMailSenderThread.checkOtherMailerStatus(EPMailSenderThread.java:2799) at ep.server.epmailer.EPMailSenderThread.run(EPMailSenderThread.java:438) at java.lang.Thread.run(Thread.java:662) Thread-6290 daemon prio=10 tid=0x7f65cc1b8800 nid=0x6376 waiting for monitor entry [0x7f65c68e6000] java.lang.Thread.State: BLOCKED (on object monitor) at ep.server.epmailer.util.EPPoolingDataSource.getConnection(EPPoolingDataSource.java:72) - waiting to lock 0xfb430c20 (a java.lang.Class for ep.server.epmailer.util.EPPoolingDataSource) at ep.server.epmailer.EPMailSenderThread.checkOtherMailerStatus(EPMailSenderThread.java:2799) at ep.server.epmailer.EPMailSenderThread.run(EPMailSenderThread.java:438) at java.lang.Thread.run(Thread.java:662) Thread-6289 daemon prio=10 tid=0x7f65cc318800 nid=0x6375
[jira] [Resolved] (COLLECTIONS-438) ExtendedProperties : String only composed of spaces character
[ https://issues.apache.org/jira/browse/COLLECTIONS-438?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Thomas Neidhart resolved COLLECTIONS-438. - Resolution: Invalid ExtendedProperties : String only composed of spaces character - Key: COLLECTIONS-438 URL: https://issues.apache.org/jira/browse/COLLECTIONS-438 Project: Commons Collections Issue Type: Bug Components: Collection Reporter: Guillaume Chauvet Attachments: COLLECTIONS-438.patch We have discovered a bug in ExtendedProperties class used in our internal language manager framework. The cause are strings which contains only spaces character. We provide a patch to complete the JUnit class ExtendedPropertiesTest. -- 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] (LANG-864) Collection wrappers to for unmodifiable / nonnull-safe collections
[
https://issues.apache.org/jira/browse/LANG-864?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=13559710#comment-13559710
]
Duncan Jones commented on LANG-864:
---
I completely agree. There was talk recently on the mailing lists about getting
moving on a new Collections release - I'm sure they'd appreciate the support.
I suggest we close this bug as a WONTFIX.
Collection wrappers to for unmodifiable / nonnull-safe collections
--
Key: LANG-864
URL: https://issues.apache.org/jira/browse/LANG-864
Project: Commons Lang
Issue Type: New Feature
Components: General
Reporter: offbynull
Priority: Minor
Would it be possible to add something like this to commons lang? Commons
collection looks like it's pretty much dead, and the only alternative for
this kind of stuff is Google's horribly designed and massively confusing
Guava library.
Below are a couple of quick and dirty (untested) examples of the kind of
wrappers I'm talking about. Note the isLocked/locked methods and the
viewBlacklist method. Using these methods, it's easy for a component
receiving a list/set to identify that it's currently unmodifiable and that
the collection restricts certain values (e.g. null? maybe others?).
{code}
public final class LockableBlacklistableListT implements ListT {
private boolean locked;
private ListT list;
private SetT blacklist;
public LockableBlacklistableList(ListT backingList, T... blacklist) {
if (backingList == null) {
throw new NullPointerException();
}
if (!backingList.isEmpty()) {
throw new IllegalArgumentException();
}
this.blacklist = new HashSet(Arrays.asList(blacklist));
this.list = backingList;
}
public void lock() {
locked = true;
}
public boolean isLocked() {
return locked;
}
public SetT viewBlacklist() {
return Collections.unmodifiableSet(blacklist);
}
@Override
public int size() {
return list.size();
}
@Override
public boolean isEmpty() {
return list.isEmpty();
}
@Override
public boolean contains(Object o) {
return list.contains(o);
}
@Override
public IteratorT iterator() {
final IteratorT it = list.iterator();
return new IteratorT() {
@Override
public boolean hasNext() {
return it.hasNext();
}
@Override
public T next() {
return it.next();
}
@Override
public void remove() {
if (locked) {
throw new IllegalStateException();
}
it.remove();
}
};
}
@Override
public Object[] toArray() {
return list.toArray();
}
@Override
public T T[] toArray(T[] a) {
return list.toArray(a);
}
@Override
public boolean add(T e) {
if (locked) {
throw new IllegalStateException();
}
return list.add(e);
}
@Override
public boolean remove(Object o) {
if (locked) {
throw new IllegalStateException();
}
return list.remove(o);
}
@Override
public boolean containsAll(Collection? c) {
return list.containsAll(c);
}
@Override
public boolean addAll(Collection? extends T c) {
if (locked) {
throw new IllegalStateException();
}
for (T item : c) {
if (blacklist.contains(item)) {
throw new IllegalArgumentException();
}
}
return list.addAll(c);
}
@Override
public boolean addAll(int index, Collection? extends T c) {
if (locked) {
throw new IllegalStateException();
}
for (T item : c) {
if (blacklist.contains(item)) {
throw new IllegalArgumentException();
}
}
return list.addAll(index, c);
}
@Override
public boolean removeAll(Collection? c) {
if (locked) {
throw new IllegalStateException();
}
return list.removeAll(c);
}
@Override
public boolean retainAll(Collection? c) {
if (locked) {
throw new IllegalStateException();
}
return list.retainAll(c);
}
@Override
public void clear() {
if (locked) {
throw new IllegalStateException();
}
list.clear();
}
@Override
public boolean equals(Object o) {
return list.equals(o);
[jira] [Created] (COMPRESS-216) JarArchiveEntry manifestAttributes and certificates are always null
Sebb created COMPRESS-216: - Summary: JarArchiveEntry manifestAttributes and certificates are always null Key: COMPRESS-216 URL: https://issues.apache.org/jira/browse/COMPRESS-216 Project: Commons Compress Issue Type: Bug Reporter: Sebb Priority: Minor JarArchiveEntry manifestAttributes and certificates are always null - is that intentional? In any case the Javadoc should state that the response is always null. Also, why does getCertificates() return null rather than an empty array? -- 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] (CONFIGURATION-521) fileFromUrl: decoding of encoded % character does not work
[
https://issues.apache.org/jira/browse/CONFIGURATION-521?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=13559994#comment-13559994
]
Oliver Heger commented on CONFIGURATION-521:
I understand the motivation to keep the code as close to the origin as possible
so that it is easier to detect deviations in future. However, for multiple
reasons I am not happy with the current state of the solution:
* Having a single method in a class formatted differently looks strange. There
is a high probability that it is reformatted later, maybe by accident.
* Checkstyle will complain. (I am not sure whether it is possible to filter on
specific methods.)
* The method name {{toFile()}} is not very speaking. It makes sense in the
context of {{FileUtils}} where there is a bunch of overloaded conversion
methods, but for {{ConfigurationUtils}} you don't see on a single glance what
it is expected to do.
How about the following compromise:
* We create a new class {{FileUtils}} next to {{ConfigurationUtils}} with
default visibility so that it does not become part of the public API.
* In the Javadoc of this class it is stated that it contains code copied from
Commons IO.
* The {{toFile()}} method is copied literally.
* {{ConfigurationUtils}} keeps its {{fileFromURL()}} method, but the
implementation delegates to {{FileUtils}}.
* In the checkstyle suppression configuration the {{FileUtils}} class can be
excluded.
Does this make sense?
fileFromUrl: decoding of encoded % character does not work
--
Key: CONFIGURATION-521
URL: https://issues.apache.org/jira/browse/CONFIGURATION-521
Project: Commons Configuration
Issue Type: Bug
Affects Versions: 1.9
Reporter: Oliver Kopp
Attachments: fileFromUrl.patch,
update-to-FileUtils-rev1349509-keepting-name-fileFromUrl.patch,
update-to-FileUtils-rev1349509.patch
If ConfigurationUtils.fileFromUrl(URL) should create a file from a URL
containing an enoced % sign (%25), then it does not work.
I saw that the code apache.commons.io now is really different, but seems to
work. Why isn't apache.commons.io directly used?
--
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] (CONFIGURATION-521) fileFromUrl: decoding of encoded % character does not work
[ https://issues.apache.org/jira/browse/CONFIGURATION-521?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Oliver Kopp updated CONFIGURATION-521: -- Attachment: update-to-FileUtils-rev1423916-separating-FileUtils.patch fileFromUrl: decoding of encoded % character does not work -- Key: CONFIGURATION-521 URL: https://issues.apache.org/jira/browse/CONFIGURATION-521 Project: Commons Configuration Issue Type: Bug Affects Versions: 1.9 Reporter: Oliver Kopp Attachments: fileFromUrl.patch, update-to-FileUtils-rev1349509-keepting-name-fileFromUrl.patch, update-to-FileUtils-rev1349509.patch, update-to-FileUtils-rev1423916-separating-FileUtils.patch If ConfigurationUtils.fileFromUrl(URL) should create a file from a URL containing an enoced % sign (%25), then it does not work. I saw that the code apache.commons.io now is really different, but seems to work. Why isn't apache.commons.io directly used? -- 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] (CONFIGURATION-521) fileFromUrl: decoding of encoded % character does not work
[ https://issues.apache.org/jira/browse/CONFIGURATION-521?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=13560154#comment-13560154 ] Oliver Kopp commented on CONFIGURATION-521: --- It does definitely make sense. I added another patch. Hope, the new checkstyle rule works. fileFromUrl: decoding of encoded % character does not work -- Key: CONFIGURATION-521 URL: https://issues.apache.org/jira/browse/CONFIGURATION-521 Project: Commons Configuration Issue Type: Bug Affects Versions: 1.9 Reporter: Oliver Kopp Attachments: fileFromUrl.patch, update-to-FileUtils-rev1349509-keepting-name-fileFromUrl.patch, update-to-FileUtils-rev1349509.patch, update-to-FileUtils-rev1423916-separating-FileUtils.patch If ConfigurationUtils.fileFromUrl(URL) should create a file from a URL containing an enoced % sign (%25), then it does not work. I saw that the code apache.commons.io now is really different, but seems to work. Why isn't apache.commons.io directly used? -- 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] (NET-488) ftpclient.listfiles return file name as FILE1.236 -rw-rw-r-- 1 T0000001 FTP 5242484 Oct 15 18:20 FILE1.237
[
https://issues.apache.org/jira/browse/NET-488?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Sebb updated NET-488:
-
Priority: Major (was: Critical)
Description:
while listing files from the FTP server ftpclient.listfiles return file name as
{noformat}
file name 1 -rw-rw-r--1 T001 FTP5242484 Oct 15 18:20 file
name 2.
{noformat}
the single string contains two file name and carriage return character is at
end of line.sometimes, second file doesnot come under the list or missing from
the list.
However, the list contains all valid file name except the one bad string.It
occurs not consistently.
was:
while listing files from the FTP server ftpclient.listfiles return file name as
file name 1 -rw-rw-r--1 T001 FTP5242484 Oct 15 18:20 file
name 2.
the single string contains two file name and carriage return character is at
end of line.sometimes, second file doesnot come under the list or missing from
the list.
However, the list contains all valid file name except the one bad string.It
occurs not consistently.
ftpclient.listfiles return file name as FILE1.236 -rw-rw-r--1 T001
FTP5242484 Oct 15 18:20 FILE1.237
-
Key: NET-488
URL: https://issues.apache.org/jira/browse/NET-488
Project: Commons Net
Issue Type: Bug
Components: FTP
Affects Versions: 3.1
Environment: FTP SERVER UNIX, FTP CLIENT=windows and connect through
Websphere application server version 6.1
Reporter: suman mehta
while listing files from the FTP server ftpclient.listfiles return file name
as
{noformat}
file name 1 -rw-rw-r--1 T001 FTP5242484 Oct 15 18:20 file
name 2.
{noformat}
the single string contains two file name and carriage return character is at
end of line.sometimes, second file doesnot come under the list or missing
from the list.
However, the list contains all valid file name except the one bad string.It
occurs not consistently.
--
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-488) ftpclient.listfiles return file name as FILE1.236 -rw-rw-r-- 1 T0000001 FTP 5242484 Oct 15 18:20 FILE1.237
[
https://issues.apache.org/jira/browse/NET-488?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=13560211#comment-13560211
]
Sebb commented on NET-488:
--
What are the actual file details on the server that cause the problem?
ftpclient.listfiles return file name as FILE1.236 -rw-rw-r--1 T001
FTP5242484 Oct 15 18:20 FILE1.237
-
Key: NET-488
URL: https://issues.apache.org/jira/browse/NET-488
Project: Commons Net
Issue Type: Bug
Components: FTP
Affects Versions: 3.1
Environment: FTP SERVER UNIX, FTP CLIENT=windows and connect through
Websphere application server version 6.1
Reporter: suman mehta
while listing files from the FTP server ftpclient.listfiles return file name
as
{noformat}
file name 1 -rw-rw-r--1 T001 FTP5242484 Oct 15 18:20 file
name 2.
{noformat}
the single string contains two file name and carriage return character is at
end of line.sometimes, second file doesnot come under the list or missing
from the list.
However, the list contains all valid file name except the one bad string.It
occurs not consistently.
--
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] [Resolved] (NET-480) Wrong passivHost when using FTPHTTPClient with EPSV
[ https://issues.apache.org/jira/browse/NET-480?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Sebb resolved NET-480. -- Resolution: Fixed Fix Version/s: 3.3 Finally got around to looking at this again. It looks like the work-round you used is necessary, so committed it: URL: http://svn.apache.org/viewvc?rev=1437243view=rev Log: NET-480 Wrong passivHost when using FTPHTTPClient with EPSV Modified: commons/proper/net/trunk/src/changes/changes.xml commons/proper/net/trunk/src/main/java/org/apache/commons/net/ftp/FTPHTTPClient.java Wrong passivHost when using FTPHTTPClient with EPSV --- Key: NET-480 URL: https://issues.apache.org/jira/browse/NET-480 Project: Commons Net Issue Type: Bug Components: FTP Affects Versions: 3.1 Environment: All Systems with ftp Access over http Reporter: Peter Naber Fix For: 3.3 Attachments: FTPSquidProxyClient.java At the FTPHTTPClient Class in line 99 the Answer from the EPSV Command will parse to receive the Data port and the passiv Host. \_parsePassiveModeReply(\_replyLines.get(0)) In this function the \_\_passivHost is set to the remoteAddress, but this address is determine by this.\_socket\_.getInetAddress(); and the socket is the socket of the proxy Server and NOT of the ftp Server. -- 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] (NET-480) Wrong passivHost when using FTPHTTPClient with EPSV
[ https://issues.apache.org/jira/browse/NET-480?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Sebb updated NET-480: - Affects Version/s: 3.2 Wrong passivHost when using FTPHTTPClient with EPSV --- Key: NET-480 URL: https://issues.apache.org/jira/browse/NET-480 Project: Commons Net Issue Type: Bug Components: FTP Affects Versions: 3.1, 3.2 Environment: All Systems with ftp Access over http Reporter: Peter Naber Fix For: 3.3 Attachments: FTPSquidProxyClient.java At the FTPHTTPClient Class in line 99 the Answer from the EPSV Command will parse to receive the Data port and the passiv Host. \_parsePassiveModeReply(\_replyLines.get(0)) In this function the \_\_passivHost is set to the remoteAddress, but this address is determine by this.\_socket\_.getInetAddress(); and the socket is the socket of the proxy Server and NOT of the ftp Server. -- 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] [Resolved] (NET-492) FTPClient.printWorkingDirectory() incorrectly parses certain valid PWD command results
[ https://issues.apache.org/jira/browse/NET-492?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Sebb resolved NET-492. -- Resolution: Fixed Fix Version/s: 3.3 I assume the latest change fixed the problem. If not, please re-open with full details. FTPClient.printWorkingDirectory() incorrectly parses certain valid PWD command results -- Key: NET-492 URL: https://issues.apache.org/jira/browse/NET-492 Project: Commons Net Issue Type: Bug Components: FTP Affects Versions: 3.2 Reporter: Tomasz Jedrzejewski Priority: Minor Fix For: 3.3 The new implementation of FTPClient.printWorkingDirectory() which tries to follow RFC959 is invalid and can return unescaped or invalid path in certain circumstances. According to the commentary, the author interpreted the RFC that the output is always constructed in the following way: 257spacedirectory-namespacecommentary Where any double quotes within the directory name are doubled. First issue: the RFC does not state that the output for PWD looks exactly like this, but that the reply code is the same, as for MKD. Especially, PWD does not return any commentary, and VSFTPD server (which I'm trying to talk to) does not print out the terminating space, but ends up the output on the last double quote. The algorithm uses the following code to detect the end of the quoted path: int end = reply.lastIndexOf(\ ); If there is no terminating space, the last double quote cannot be found, and as a result, the method returns the unescaped directory name: /foo instead of /foo Second issue: the current implementation would not work in case of the following directory: /Foo/Bar /Joe PWD command output: 257 /Foo/Bar /Joe Value returned by printWorkingDirectory(): /Foo/Bar Note to the administrators: the problem has been found in commons-net 3.2 version, but JIRA claims it is unreleased and does not allow me to choose it. -- 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] [Resolved] (COMPRESS-216) JarArchiveEntry manifestAttributes and certificates are always null
[ https://issues.apache.org/jira/browse/COMPRESS-216?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Stefan Bodewig resolved COMPRESS-216. - Resolution: Duplicate we had deferred fixing it to when we are willing to break the API. JarArchiveEntry manifestAttributes and certificates are always null --- Key: COMPRESS-216 URL: https://issues.apache.org/jira/browse/COMPRESS-216 Project: Commons Compress Issue Type: Bug Reporter: Sebb Priority: Minor JarArchiveEntry manifestAttributes and certificates are always null - is that intentional? In any case the Javadoc should state that the response is always null. Also, why does getCertificates() return null rather than an empty array? -- 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
