Nabble - Commons - Issues

[jira] Commented: (NET-89) [net] TelnetClient broken for binary transmissions + solution

2009-11-22T04:26:39Z

[ https://issues.apache.org/jira/browse/NET-89?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=12781119#action_12781119 ]

Shlomy Reinstein commented on NET-89:
-------------------------------------

I have a different case in which the ToNetASCIIInputStream causes a problem. I use text transmissions, not binary, however the telnet server does not seem to tell the difference between '\r' and '\n', and so the replacement of '\n' with "\r\n" causes every line I send to generate an extra newline, which prevents automation (e.g. in the login/password sequence, the password is always passed as empty due to the extra newline).

I suggest to add a method like the "setNetASCIIConversion(boolean)" above, and even have a dedicated one for the just the telnet's output - i.e. avoid only the wrapper ToNetASCIIOutputStream. Something like:

public void setNetASCIIConversionOnOutput(boolean b);
public void setNetASCIIConversionOnInput(boolean b);

The "set" functions can be replaced by "disable" if the default is to have them enabled. Another option, which seems better to me, is to replace these functions with new TelnetClient constructors that take an additional boolean parameter (or two), to ensure this is configured before the connection is made.

Thanks,
Shlomy

> [net] TelnetClient broken for binary transmissions + solution
> -------------------------------------------------------------
>
> Key: NET-89
> URL: https://issues.apache.org/jira/browse/NET-89
> Project: Commons Net
> Issue Type: Bug
> Environment: Operating System: All
> Platform: All
> Reporter: Colin Surprenant
>
> TelnetClient does not handle correctly binary transmissions in two places:
> First in TelnetClient#_connectAction_() the telnet input and output streams are
> wrapped in the NetASCII streams to handle net vs platform line separator
> conversion which breaks the binary data. My quick solution was to simply remove
> those two wrapping streams. A more general solution might be to provide access
> to the unfilterer stream with methods like getUnfilteredInputStream and
> getUnfilteredOutputStream or to dynamically stop the NetASCII stream from
> 'corrupting' the stream when a TelnetOption.BINARY option is negotiated.
> Also, in TelnetInoutStream#__read() there is a bug in the __receiveState
> handling for the _STATE_IAC state. When a second consecutive IAC (0x255) is
> received to encode the single 0x255 character, read does not return 0x255 but
> instead move on to reading the next char in the stream.
> The current code reads:
> case _STATE_IAC:
> switch (ch)
> {
> case TelnetCommand.WILL:
> __receiveState = _STATE_WILL;
> continue;
> case TelnetCommand.WONT:
> __receiveState = _STATE_WONT;
> continue;
> case TelnetCommand.DO:
> __receiveState = _STATE_DO;
> continue;
> case TelnetCommand.DONT:
> __receiveState = _STATE_DONT;
> continue;
> /* TERMINAL-TYPE option (start)*/
> case TelnetCommand.SB:
> __suboption_count = 0;
> __receiveState = _STATE_SB;
> continue;
> /* TERMINAL-TYPE option (end)*/
> case TelnetCommand.IAC:
> __receiveState = _STATE_DATA;
> break;
> default:
> break;
> }
> __receiveState = _STATE_DATA;
> continue;
> case _STATE_WILL:
> but it should be:
> case _STATE_IAC:
> switch (ch)
> {
> case TelnetCommand.WILL:
> __receiveState = _STATE_WILL;
> continue;
> case TelnetCommand.WONT:
> __receiveState = _STATE_WONT;
> continue;
> case TelnetCommand.DO:
> __receiveState = _STATE_DO;
> continue;
> case TelnetCommand.DONT:
> __receiveState = _STATE_DONT;
> continue;
> /* TERMINAL-TYPE option (start)*/
> case TelnetCommand.SB:
> __suboption_count = 0;
> __receiveState = _STATE_SB;
> continue;
> /* TERMINAL-TYPE option (end)*/
> case TelnetCommand.IAC:
> __receiveState = _STATE_DATA;
> break; // exit to enclosing switch to return from read
> default:
> __receiveState = _STATE_DATA;
> continue; // move on the next char
> }
> break; // exit and return from read
> case _STATE_WILL:
> I'll provide patches for this.
> Colin.

--
This message is automatically generated by JIRA.
-
You can reply to this email to add a comment to the issue online.

[jira] Created: (LANG-557) Javadoc wrong for StringUtils startsWith, startsWithIgnoreCase, endsWith and endsWithIgnoreCase

2009-11-22T04:00:40Z

Javadoc wrong for StringUtils startsWith, startsWithIgnoreCase, endsWith and endsWithIgnoreCase
-----------------------------------------------------------------------------------------------

Key: LANG-557
URL: https://issues.apache.org/jira/browse/LANG-557
Project: Commons Lang
Issue Type: Bug
Affects Versions: 2.4
Environment: http://commons.apache.org/lang//api/org/apache/commons/lang/StringUtils.html
Reporter: Anish K George

In the examples given along with the descriptions of startsWith, startsWithIgnoreCase, endsWith and endsWithIgnoreCase of StringUtils class, the full string and the suffix/prefix are used in the wrong order.

eg:

It is mentioned that StringUtils.startsWith("abc", "abcdef") = true
It should be StringUtils.startsWith("abcdef", "abc") = true

--
This message is automatically generated by JIRA.
-
You can reply to this email to add a comment to the issue online.

[jira] Created: (CODEC-91) Handling of embedded padding in base64 encoded data changed in 1.4

2009-11-21T18:52:39Z

Handling of embedded padding in base64 encoded data changed in 1.4
------------------------------------------------------------------

Key: CODEC-91
URL: https://issues.apache.org/jira/browse/CODEC-91
Project: Commons Codec
Issue Type: Bug
Affects Versions: 1.4
Reporter: Chris Pimlott

1.4 changed the way that embedded padding characters (i.e. "=") were handled when decoding base64 data. Previously, the decoder ignored them and decoded all the data. Now it stops upon encountering the first padding byte. This breaks compatibility with previous versions.

For example, in 1.4,

b64.decode("Y29tbW9ucwo=".getBytes());

gives the same result as

b64.decode("Y29tbW9ucwo=Y29tbW9ucwo=".getBytes());

--
This message is automatically generated by JIRA.
-
You can reply to this email to add a comment to the issue online.

[jira] Resolved: (DBCP-204) BasicDataSource doesn't include CallableStatement Pooling

2009-11-21T12:10:39Z

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

Phil Steitz resolved DBCP-204.
------------------------------

Resolution: Fixed

Patch applied with minor changes in r882981.

Changes:
* Allowed PoolableCallableStatement to be closed twice (consistent with new behavior in PoolablePreparedStatement)
* Added test cases
* Javadoc

Thanks!

> BasicDataSource doesn't include CallableStatement Pooling
> ---------------------------------------------------------
>
> Key: DBCP-204
> URL: https://issues.apache.org/jira/browse/DBCP-204
> Project: Commons Dbcp
> Issue Type: New Feature
> Affects Versions: 1.2.1
> Environment: All
> Reporter: Wei Chen
> Assignee: Phil Steitz
> Priority: Minor
> Fix For: 1.3
>
> Attachments: PoolingCallableStatment.patch
>
>
> Hello =)
> I had explored DBCP source code to cook for my project need recently.
> As it's said that the Database Connection Pool (DBCP) component can be used in applications where JDBC resources need to be pooled.
> "Apart from JDBC connections, this provides support for pooling Statement and PreparedStatement instances as well."
> I am curious that why it does not support for pooling CallableStatement.
> Does anybody know why the developer did not implement this furture?Are there some special consideration or some reason else?

--
This message is automatically generated by JIRA.
-
You can reply to this email to add a comment to the issue online.

[jira] Updated: (NET-300) FTPClient.listFiles() throws NullPointerException if listHiddenFiles is TRUE

2009-11-21T08:33:39Z

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

Kirill Safonov updated NET-300:
-------------------------------

Attachment: NET-300.patch

patch attached

> FTPClient.listFiles() throws NullPointerException if listHiddenFiles is TRUE
> ----------------------------------------------------------------------------
>
> Key: NET-300
> URL: https://issues.apache.org/jira/browse/NET-300
> Project: Commons Net
> Issue Type: Bug
> Affects Versions: 2.0
> Reporter: Kirill Safonov
> Attachments: NET-300.patch
>
>
> When listHiddenFiles is TRUE FTPClient.getListArguments() code determines the length of pathname parameter to create the appropriate StringBuffer (FtpClient.java:2319).
> Still pathname may merely be null if I call FTPClient.listFiles() - the one without params

--
This message is automatically generated by JIRA.
-
You can reply to this email to add a comment to the issue online.

[jira] Created: (NET-300) FTPClient.listFiles() throws NullPointerException if listHiddenFiles is TRUE

2009-11-21T08:01:40Z

FTPClient.listFiles() throws NullPointerException if listHiddenFiles is TRUE
----------------------------------------------------------------------------

Key: NET-300
URL: https://issues.apache.org/jira/browse/NET-300
Project: Commons Net
Issue Type: Bug
Affects Versions: 2.0
Reporter: Kirill Safonov

When listHiddenFiles is TRUE FTPClient.getListArguments() code determines the length of pathname parameter to create the appropriate StringBuffer (FtpClient.java:2319).
Still pathname may merely be null if I call FTPClient.listFiles() - the one without params

--
This message is automatically generated by JIRA.
-
You can reply to this email to add a comment to the issue online.

[jira] Updated: (LANG-454) Add getCharArray() to CharRange

2009-11-21T00:34:43Z

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

Henri Yandell updated LANG-454:
-------------------------------

Comment: was deleted

(was: A bit dependent on whether CharRange goes away and is replaced by Range. This would be possible with Range as there's no way to infer the next element in the range.

Possibly CharRange would be a subclass of Range. Having the two separate doesn't feel good, but supporting the '^' feature feels weird in Range currently.)

> Add getCharArray() to CharRange
> --------------------------------
>
> Key: LANG-454
> URL: https://issues.apache.org/jira/browse/LANG-454
> Project: Commons Lang
> Issue Type: Improvement
> Affects Versions: 2.4
> Reporter: Kenny MacLeod
> Fix For: 3.0
>
> Attachments: LANG-454-iterator.patch, LANG-454-set.patch, LANG-454.patch
>
>
> org.apache.commons.lang.CharRange would be a lot more useful if it had a means to obtain the characters in the range as a char array.
> i.e.
> new CharRange('a',''d').toCharArray() == new char[] { 'a', 'b', 'c', 'd' }

--
This message is automatically generated by JIRA.
-
You can reply to this email to add a comment to the issue online.

[jira] Updated: (LANG-454) Add getCharArray() to CharRange

2009-11-21T00:34:41Z

--
This message is automatically generated by JIRA.
-
You can reply to this email to add a comment to the issue online.

[jira] Closed: (POOL-147) Thread stuck in GenericObjectPool borrowObject()

2009-11-20T13:07:39Z

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

Phil Steitz closed POOL-147.
----------------------------

> Thread stuck in GenericObjectPool borrowObject()
> ------------------------------------------------
>
> Key: POOL-147
> URL: https://issues.apache.org/jira/browse/POOL-147
> Project: Commons Pool
> Issue Type: Bug
> Affects Versions: 1.5.1
> Reporter: Giambattista Bloisi
> Priority: Minor
> Fix For: 1.5.2
>
> Attachments: 01-borrowObject.patch
>
>
> In my application I found a thread stuck at GenericObjectPool.borrowObject(GenericObjectPool.java:1099) even though resources were availbale (in my case connections for DBCP).
> After an analysis of the code I think I spotted what could have caused this behavior. GenericObjectPool.java:1099 line corresponds to an indefinite wait to a "latch" object. This wait should be awaken when new resources are made available to the pool. The problem is likely that borrowObject enters in wait without performing "latch.getPair()" check in a critical section.

--
This message is automatically generated by JIRA.
-
You can reply to this email to add a comment to the issue online.

[jira] Closed: (POOL-152) GenericObjectPool hangs forever in borrowObject when newly created object is not validated

2009-11-20T13:07:39Z

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

Phil Steitz closed POOL-152.
----------------------------

> GenericObjectPool hangs forever in borrowObject when newly created object is not validated
> ------------------------------------------------------------------------------------------
>
> Key: POOL-152
> URL: https://issues.apache.org/jira/browse/POOL-152
> Project: Commons Pool
> Issue Type: Bug
> Affects Versions: 1.5.2, 1.5.3
> Reporter: Bushov Alexander
> Fix For: 1.5.4
>
> Attachments: borrowObject.patch, Test.java
>
>
> If your set GenericObjectPool parameters such as: maxActive = 1 and whenExhaustedAction to block, testOnBorrow to true, call borrowObject that fails in validation of newly created object then second call of borrowObject will stuck.

--
This message is automatically generated by JIRA.
-
You can reply to this email to add a comment to the issue online.

[jira] Created: (SCXML-113) Log not initialized in 2 of 4 AbstractStateMachine constructors.

2009-11-20T11:49:39Z

Log not initialized in 2 of 4 AbstractStateMachine constructors.
----------------------------------------------------------------

Key: SCXML-113
URL: https://issues.apache.org/jira/browse/SCXML-113
Project: Commons SCXML
Issue Type: Bug
Affects Versions: 0.9
Reporter: Eric Gulatee
Priority: Blocker

"Log" in AbstractStateMachine is NOT initialized if using either of these two constructors.

This causes a NPE if a failure occurs while initializing the state machine.

/**
* Convenience constructor.
*
* @param stateMachine The parsed SCXML instance that
* describes the "lifecycle" of the
* instances of this class.
*
* @since 0.7
*/
public AbstractStateMachine(final SCXML stateMachine) {
// default is JEXL
this(stateMachine, new JexlContext(), new JexlEvaluator());
}

/**
* Primary constructor.
*
* @param stateMachine The parsed SCXML instance that
* describes the "lifecycle" of the
* instances of this class.
* @param rootCtx The root context for this instance.
* @param evaluator The expression evaluator for this instance.
*
* @see Context
* @see Evaluator
*
* @since 0.7
*/
public AbstractStateMachine(final SCXML stateMachine,
final Context rootCtx, final Evaluator evaluator) {
initialize(stateMachine, rootCtx, evaluator);
}

--
This message is automatically generated by JIRA.
-
You can reply to this email to add a comment to the issue online.

[jira] Commented: (SANSELAN-21) Fetching GPS Latitude Ref gets Interoperability Index instead of Reference

2009-11-20T04:27:39Z

[ https://issues.apache.org/jira/browse/SANSELAN-21?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=12780536#action_12780536 ]

FG commented on SANSELAN-21:
----------------------------

confirmed, using geo1.jpg:
IrfanView correctly extracts the GeoTags:
GPS Version ID: 2.2.0.0
GPS Latitude Ref: N
GPS Latitude: 47 49 2.29
GPS Longitude Ref: E
GPS Longitude: 11, 36, 40.114

while Sanselan produces the following output
GPS Version ID: Not Found.
GPS Latitude Ref: 'R98' <- should be N?
GPS Latitude: 48, 49, 48, 48<- should be 47 49 2.29?
GPS Longitude Ref: 'E'
GPS Longitude: 11, 36, 40114/1000 (40,114)

static void getLocation(File file) throws IOException, ImageReadException {
IImageMetadata metadata = Sanselan.getMetadata(file);
if (metadata instanceof JpegImageMetadata) {
JpegImageMetadata jpegMetadata = (JpegImageMetadata) metadata;
for (TagInfo ti : GPSTagConstants.ALL_GPS_TAGS) {
TiffField field = jpegMetadata.findEXIFValue(ti);
if (field != null) {
System.out.println(ti.name + ": " + field.getValueDescription());
}
}
}
}

> Fetching GPS Latitude Ref gets Interoperability Index instead of Reference
> --------------------------------------------------------------------------
>
> Key: SANSELAN-21
> URL: https://issues.apache.org/jira/browse/SANSELAN-21
> Project: Commons Sanselan
> Issue Type: Bug
> Affects Versions: 0.94-incubator
> Environment: Windows XP SP3, java version "1.5.0_17"
> apache-sanselan-incubating-0.97-bin.zip
> Reporter: Christian Junk
> Priority: Minor
> Attachments: geo1.jpg, R0013102.jpg
>
>
> When testing the following example
> https://svn.apache.org/repos/asf/incubator/sanselan/trunk/src/test/java/org/apache/sanselan/sampleUsage/MetadataExample.java
> with apache-sanselan-incubating-0.97 it always stops working throwing a ClassCastException. It seems, that the line
> TiffField gpsLatitudeRefField = jpegMetadata
> .findEXIFValue(TiffConstants.GPS_TAG_GPS_LATITUDE_REF);
> returns the Interoperability Index (R98) instead of the GPS Latitude Ref.
> XResolution: 72
> Date Time: '2008:07:23 18:19:58'
> Date Time Original: '2008:07:23 10:05:21'
> Create Date: '2008:07:23 10:05:21'
> ISO: 64
> Shutter Speed Value: Not Found.
> Aperture Value: 6
> Brightness Value: 81/10 (8,1)
> GPS Latitude Ref: 'R98' <------------------------------------ !!!!!!!
> GPS Latitude: 48, 49, 48, 48
> GPS Longitude Ref: 'E'
> GPS Longitude: 6, 38, 2061/100 (20,61)
> GPS Description: [GPS. Latitude: 49 degrees, 45 minutes, 34,18 seconds N, Longitude: 6 degrees, 38 minutes, 20,61 seconds E]
>
> Exception in thread "main" java.lang.ClassCastException: [B
> at com.alta4.phasr.MetadataExample.metadataExample(MetadataExample.java:113)

--
This message is automatically generated by JIRA.
-
You can reply to this email to add a comment to the issue online.

[jira] Updated: (SANSELAN-21) Fetching GPS Latitude Ref gets Interoperability Index instead of Reference

2009-11-20T04:23:39Z

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

FG updated SANSELAN-21:
-----------------------

Attachment: geo1.jpg

file to demonstrate geotag error

--
This message is automatically generated by JIRA.
-
You can reply to this email to add a comment to the issue online.

[jira] Commented: (LANG-556) Add methods for constructing dates to DateUtils

2009-11-19T12:29:39Z

[ https://issues.apache.org/jira/browse/LANG-556?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=12780256#action_12780256 ]

Paul Benedict commented on LANG-556:
------------------------------------

You can find this feature in the JDK:
new GregorianCalendar(year, month, day, hour, minute, second).getTime();

> Add methods for constructing dates to DateUtils
> -----------------------------------------------
>
> Key: LANG-556
> URL: https://issues.apache.org/jira/browse/LANG-556
> Project: Commons Lang
> Issue Type: New Feature
> Reporter: Ben Arnold
> Priority: Minor
>
> It is often really useful to be able to get a date in one line of code, particularly in unit tests. It is also handy to be able to obtain the current time in a specified timezone.
> It would be great to have methods like these on DateUtils:
> Date now(TimeZone)
> Date nowUtc()
> Date createDate(int year, int month, int day) // local time
> Date createDate(int year, int month, int day, int hour, minute, int second) // local time
> Date createDateUtc(int year, int month, int day)
> Date createDateUtc(int year, int month, int day, int hour, minute, int second)
> Date createDate(TimeZone timeZone, int year, int month, int day)
> Date createDate(TimeZone timeZone, int year, int month, int day, int hour, minute, int second)

--
This message is automatically generated by JIRA.
-
You can reply to this email to add a comment to the issue online.

[jira] Created: (LANG-556) Add methods for constructing dates to DateUtils

2009-11-19T12:23:40Z

Add methods for constructing dates to DateUtils
-----------------------------------------------

Key: LANG-556
URL: https://issues.apache.org/jira/browse/LANG-556
Project: Commons Lang
Issue Type: New Feature
Reporter: Ben Arnold
Priority: Minor

It is often really useful to be able to get a date in one line of code, particularly in unit tests. It is also handy to be able to obtain the current time in a specified timezone.

It would be great to have methods like these on DateUtils:

Date now(TimeZone)
Date nowUtc()

Date createDate(int year, int month, int day) // local time
Date createDate(int year, int month, int day, int hour, minute, int second) // local time
Date createDateUtc(int year, int month, int day)
Date createDateUtc(int year, int month, int day, int hour, minute, int second)
Date createDate(TimeZone timeZone, int year, int month, int day)
Date createDate(TimeZone timeZone, int year, int month, int day, int hour, minute, int second)

--
This message is automatically generated by JIRA.
-
You can reply to this email to add a comment to the issue online.

[jira] Created: (JXPATH-139) Wrong xpath expression passed to extension function does not throw JXPathNotFoundException

2009-11-19T10:57:39Z

Wrong xpath expression passed to extension function does not throw JXPathNotFoundException
------------------------------------------------------------------------------------------

Key: JXPATH-139
URL: https://issues.apache.org/jira/browse/JXPATH-139
Project: Commons JXPath
Issue Type: Bug
Affects Versions: 1.3
Reporter: Petras

If xpath expression, which do not map to bean properties, is passed to extension function, JXPathNotFoundException is not thrown. It seems inconsistent behaviour and it is difficult to test these expressions if they do not fail for example after code refactoring.

Here is a test case:

{code}
// Extension function
public static class StringFunctions {
public static String left(String param, int len) {
System.out.println("Received: '" + param + "'");
if(param == null) return null;
return param.substring(0, Math.min(len, param.length()));
}
}
{code}

{code}
// Value object to use
public class VO {
String value = null;
public String getValue() { return value; }
public void setValue(String value) { this.value = value; }
}

{code}
{code}
@Test
public void testLeftFunctionWrongPath() {
VO vo = new VO();
vo.setValue("1234567890");

JXPathContext ctx = JXPathContext.newContext(vo);

ctx.setFunctions(new ClassFunctions(StringFunctions.class, "util"));

// OK, StringFunctions.left() receives "1234567890"
path = "util:left(value, 5)";
ctx.getValue(path);

// JXPathNotFoundException is not thrown, StringFunctions.left() receives an empty string
String wrongPath = "util:left(valueXXX, 5)";
ctx.getValue(wrongPath);
}
{code}

--
This message is automatically generated by JIRA.
-
You can reply to this email to add a comment to the issue online.

[jira] Commented: (DBCP-305) Use API-specific exception for logging abandoned objects

2009-11-19T07:15:39Z

[ https://issues.apache.org/jira/browse/DBCP-305?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=12780022#action_12780022 ]

Christopher Schultz commented on DBCP-305:
------------------------------------------

Thanks for accepting this patch. I'm sorry I wasn't sensitive to the brace convention already in the file. I probably could have javadoc'd the inner class, too :)

I didn't think about the lack of thread safety of the SimpleDateFormat class: good catch. So this counts as a bugfix by markt (format was being used in an unsynchronized way prior to this patch) as well as an enhancement by me :)

If DBCP typically uses localized error messages, I'd be happy to provide another patch that localizes the exception's message.

> Use API-specific exception for logging abandoned objects
> --------------------------------------------------------
>
> Key: DBCP-305
> URL: https://issues.apache.org/jira/browse/DBCP-305
> Project: Commons Dbcp
> Issue Type: Improvement
> Reporter: Christopher Schultz
> Assignee: Mark Thomas
> Priority: Trivial
> Fix For: 1.3
>
> Attachments: DBCP-305.diff
>
>
> When a DBCP-managed object (Connection, Statement, etc.) is considered "abandoned", a stack trace is emitted to stdout. Unfortunately, the stack trace is for a simple java.lang.Exception (created in AbandonedTrace.init and AbandonedTrace.setStackTrace) with no message.
> When scanning log files for exceptions, say, like this:
> grep "Exception" my_logfile.log, I simply shows:
> java.lang.Exception
> java.lang.Exception
> java.lang.Exception
> ...
> It would be nice to use a more descriptive exception (for instance, AbandonedObjectException) and/or add a descriptive message to the exception upon creation.
> For example, it would be useful to execute the above command and see:
> org.apache.commons.dbcp.AbandonedObjectException: DBCP object created 2009-11-05 10:15:00 by the following code was never closed
> Having the timestamp and a definite identification of the exception (i.e. the class name) on the same line of log output is preferable IMO.
> Implementation should be trivial; I'd be happy to submit a patch. Also, the format of the logging information isn't part of the API itself, so it shouldn't be a big deal to change it.

--
This message is automatically generated by JIRA.
-
You can reply to this email to add a comment to the issue online.

[jira] Resolved: (DBCP-305) Use API-specific exception for logging abandoned objects

2009-11-19T03:37:40Z

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

Mark Thomas resolved DBCP-305.
------------------------------

Resolution: Fixed

Thanks for the patch. It has been applied and will be in 1.3 onwards. I modified the patch slightly to use the same { location as the rest of the class and to make access to the SimpleDateFormat thread safe.

--
This message is automatically generated by JIRA.
-
You can reply to this email to add a comment to the issue online.

[jira] Updated: (DBCP-305) Use API-specific exception for logging abandoned objects

2009-11-19T02:25:40Z

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

Mark Thomas updated DBCP-305:
-----------------------------

Fix Version/s: 1.3
Assignee: Mark Thomas

--
This message is automatically generated by JIRA.
-
You can reply to this email to add a comment to the issue online.

[jira] Commented: (NET-285) FTP should support external IP address and port range

2009-11-19T02:13:40Z

[ https://issues.apache.org/jira/browse/NET-285?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=12779917#action_12779917 ]

Binoy Joseph commented on NET-285:
----------------------------------

Hi, Hope this can be resolved

> FTP should support external IP address and port range
> -----------------------------------------------------
>
> Key: NET-285
> URL: https://issues.apache.org/jira/browse/NET-285
> Project: Commons Net
> Issue Type: New Feature
> Reporter: Binoy Joseph
> Attachments: ftpclient_active_portRange_ExtAddress.patch
>
> Original Estimate: 2h
> Remaining Estimate: 2h
>
> If you use FTP tools like FileZilla, you see that in Active mode,
> the external IP address (when client has multiple network cards) and
> port range (when client has firewall setup) are supported.
> This is very essential for an enterprise class FTP client.
> I see that a small modification in FTPClient's _openDataConnection_() method will support all this.
> _serverSocketFactory_.createServerSocket(0, 1, getLocalAddress());
> Can I also go ahead creating a patch for this?

--
This message is automatically generated by JIRA.
-
You can reply to this email to add a comment to the issue online.

[jira] Created: (CODEC-90) JDK 1.5 the API

2009-11-18T19:52:41Z

JDK 1.5 the API
---------------

Key: CODEC-90
URL: https://issues.apache.org/jira/browse/CODEC-90
Project: Commons Codec
Issue Type: Improvement
Reporter: Henri Yandell

Need to apply varargs, autoboxing and generics to the API.

--
This message is automatically generated by JIRA.
-
You can reply to this email to add a comment to the issue online.

[jira] Created: (COMPRESS-91) jar recognition is curently impossible.

2009-11-18T12:56:39Z

jar recognition is curently impossible.
---------------------------------------

Key: COMPRESS-91
URL: https://issues.apache.org/jira/browse/COMPRESS-91
Project: Commons Compress
Issue Type: Bug
Affects Versions: 1.0
Environment: W2K and unbuntu JRE1.4 to 1.6.
Reporter: Torelli
Priority: Minor

In ArchiveStreamFactory.createArchiveInputStream(final InputStream in),
JarArchiveInputStream must be before ZipArchiveInputStream

and a positive jar identification have to be confirmed by the first file entry (META-INF/MANIFEST.MF).

Regards.

--
This message is automatically generated by JIRA.
-
You can reply to this email to add a comment to the issue online.

[jira] Commented: (BEANUTILS-252) getNestedProperty doesn't work with maps properly

2009-11-18T12:28:39Z

[ https://issues.apache.org/jira/browse/BEANUTILS-252?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=12779649#action_12779649 ]

Maarten Van Avermaet commented on BEANUTILS-252:
------------------------------------------------

Why does the key of the map always requires a String, why not an object?

> getNestedProperty doesn't work with maps properly
> -------------------------------------------------
>
> Key: BEANUTILS-252
> URL: https://issues.apache.org/jira/browse/BEANUTILS-252
> Project: Commons BeanUtils
> Issue Type: Bug
> Components: Bean / Property Utils
> Affects Versions: 1.7.0
> Environment: Any
> Reporter: Masker71
>
> Hello,
> Here is an example of PropertyUtils.getProperty use:
> HashMap myMap = new HashMap();
> myMap.put("key","value");
> Request:
> System.out.println(PropertyUtils.getProperty(myMap, "(key)"));
> Result:
> null
> Workaround:
> HashMap myMap = new HashMap();
> myMap.put("(key)","value");
> Request:
> System.out.println(PropertyUtils.getProperty(myMap, "(key)"));
> Result:
> value
> The reason of this behaviour is that in the implementation of PropertyUtilsBean.getNestedProperty function.
> Currently it doesn't extract 'key' from brackets. variable name is equal to "(key)" when this method is invoked
> and it is used to extract value from the map:
> indexOfINDEXED_DELIM = name.indexOf(PropertyUtils.INDEXED_DELIM);
> indexOfMAPPED_DELIM = name.indexOf(PropertyUtils.MAPPED_DELIM);
> if (bean instanceof Map) {
> bean = ((Map) bean).get(name);
> } else if (indexOfMAPPED_DELIM >= 0) {
> bean = getMappedProperty(bean, name);
> } else if (indexOfINDEXED_DELIM >= 0) {
> bean = getIndexedProperty(bean, name);
> } else {
> bean = getSimpleProperty(bean, name);
> }
> For the bean methods which returs maps key extraction is performed, why it isn't done for the Map? Cannot I use any string as a key in the map, why should I use keys enveloped in brackets? I think what is mentioned to do is that:
> indexOfINDEXED_DELIM = name.indexOf(PropertyUtils.INDEXED_DELIM);
> indexOfMAPPED_DELIM = name.indexOf(PropertyUtils.MAPPED_DELIM);
> indexOfMAPPED_DELIM2 = name.indexOf(PropertyUtils.MAPPED_DELIM2);
> if (bean instanceof Map) {
> if (indexOfMAPPED_DELIM >= 0 && indexOfMAPPED_DELIM2>=0)
> name = name.substring(indexOfMAPPED_DELIM+1, indexOfMAPPED_DELIM2);
> bean = ((Map) bean).get(name);
> }
> Hope description was clear enough and you will approve it as a bug.
> Thank you

--
This message is automatically generated by JIRA.
-
You can reply to this email to add a comment to the issue online.

[jira] Commented: (IO-181) LineIterator should implement Iterable

2009-11-18T10:50:39Z

[ https://issues.apache.org/jira/browse/IO-181?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=12779592#action_12779592 ]

Noah Levitt commented on IO-181:
--------------------------------

> may expect that each call to Iterable.iterator returns a fresh iterator that shares no state with other iterators

Oh, right, that makes sense. Still, if something is both an Iterable and an Iterator, I think it's intuitive (and as you point out, definitely acceptable if documented) that iterator() would return itself.

> LineIterator should implement Iterable
> ---------------------------------------
>
> Key: IO-181
> URL: https://issues.apache.org/jira/browse/IO-181
> Project: Commons IO
> Issue Type: Improvement
> Affects Versions: 1.4
> Reporter: Michael Ernst
> Original Estimate: 1h
> Remaining Estimate: 1h
>
> org.apache.commons.io.LineIterator does not implement Iterable. This makes
> it impossible to use in certain stylized ways, such as in a new-style for
> statement. Such use is not always desirable (it might temporarily leak a
> file descriptor, until the finalizer is called), but should be possible in
> situations where it is known to be acceptable.

--
This message is automatically generated by JIRA.
-
You can reply to this email to add a comment to the issue online.

[jira] Resolved: (DBCP-306) the connection pool is lost after 1 hour .we need to start he app servr but after some time its again destroyed..

2009-11-18T09:28:39Z

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

Mark Thomas resolved DBCP-306.
------------------------------

Resolution: Invalid

Please use the users list for help.

> the connection pool is lost after 1 hour .we need to start he app servr but after some time its again destroyed..
> -----------------------------------------------------------------------------------------------------------------
>
> Key: DBCP-306
> URL: https://issues.apache.org/jira/browse/DBCP-306
> Project: Commons Dbcp
> Issue Type: Bug
> Affects Versions: 1.2.2
> Environment: Solaris
> Reporter: Rajiv Shaw
>
> pool is destroyed after sometime i.e the connection with the database is lost .we need to start he app servr to create the pool but after some time its again destroyed..

--
This message is automatically generated by JIRA.
-
You can reply to this email to add a comment to the issue online.

[jira] Commented: (IO-181) LineIterator should implement Iterable

2009-11-18T09:18:39Z

[ https://issues.apache.org/jira/browse/IO-181?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=12779533#action_12779533 ]

Michael Ernst commented on IO-181:
----------------------------------

The potential problem with this design is that it assumes that there is exactly one iterator for the object at a time. Clients may expect that it is possible to have multiple iterators over a given Iterable, and thus may expect that each call to Iterable.iterator returns a fresh iterator that shares no state with other iterators. (Clients shouldn't expect this in the absence of documentation, but they might.)

I think it's worth it for the convenience, so long as this behavior is documented.

--
This message is automatically generated by JIRA.
-
You can reply to this email to add a comment to the issue online.

[jira] Created: (DBCP-306) the connection pool is lost after 1 hour .we need to start he app servr but after some time its again destroyed..

2009-11-18T09:02:39Z

the connection pool is lost after 1 hour .we need to start he app servr but after some time its again destroyed..
-----------------------------------------------------------------------------------------------------------------

Key: DBCP-306
URL: https://issues.apache.org/jira/browse/DBCP-306
Project: Commons Dbcp
Issue Type: Bug
Affects Versions: 1.2.2
Environment: Solaris
Reporter: Rajiv Shaw

pool is destroyed after sometime i.e the connection with the database is lost .we need to start he app servr to create the pool but after some time its again destroyed..

--
This message is automatically generated by JIRA.
-
You can reply to this email to add a comment to the issue online.

[jira] Commented: (LANG-492) Remove code handled now by the JDK

2009-11-17T22:50:39Z

[ https://issues.apache.org/jira/browse/LANG-492?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=12779334#action_12779334 ]

Henri Yandell commented on LANG-492:
------------------------------------

hashCode removed.

toString - toString(Object[], String) isn't supported (i.e. a default value). toString(null) also fails to compile.

clone - pending JDK 1.6 dependency.

> Remove code handled now by the JDK
> ----------------------------------
>
> Key: LANG-492
> URL: https://issues.apache.org/jira/browse/LANG-492
> Project: Commons Lang
> Issue Type: Task
> Reporter: Henri Yandell
> Fix For: 3.0
>
>
> enum, enums packages removed.

--
This message is automatically generated by JIRA.
-
You can reply to this email to add a comment to the issue online.

[jira] Commented: (LANG-411) HashCodeBuilder: expose typed hashing methods

2009-11-17T22:14:39Z

[ https://issues.apache.org/jira/browse/LANG-411?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=12779324#action_12779324 ]

Paul Benedict commented on LANG-411:
------------------------------------

The default functionality of HashCodeBuilder will call static methods in ObjectUtils to create the hashes.

> HashCodeBuilder: expose typed hashing methods
> ---------------------------------------------
>
> Key: LANG-411
> URL: https://issues.apache.org/jira/browse/LANG-411
> Project: Commons Lang
> Issue Type: Wish
> Affects Versions: 2.3
> Reporter: Paul Benedict
> Priority: Minor
> Fix For: 3.0
>
>
> HashCodeBuilder encapsulates the good advice of Joshua Bloch. He details how each java.lang type should be hashed. I want to use those too ... but without reflection. Please expose those as static methods:
> hashInt, hashBoolean, etc.
> They should take two parameters: the field value, and the hash multiplier value.

--
This message is automatically generated by JIRA.
-
You can reply to this email to add a comment to the issue online.

[jira] Resolved: (LANG-555) SystemUtils needs IS_OS_WINDOWS_7 constant

2009-11-17T21:58:40Z

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

Paul Benedict resolved LANG-555.
--------------------------------

Resolution: Fixed

> SystemUtils needs IS_OS_WINDOWS_7 constant
> ------------------------------------------
>
> Key: LANG-555
> URL: https://issues.apache.org/jira/browse/LANG-555
> Project: Commons Lang
> Issue Type: Improvement
> Reporter: Paul Benedict
> Assignee: Paul Benedict
> Priority: Minor
> Fix For: 3.0
>
>

--
This message is automatically generated by JIRA.
-
You can reply to this email to add a comment to the issue online.

[jira] Resolved: (LANG-554) SystemUtils needs IS_JAVA_1_7 constant

2009-11-17T21:54:40Z

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

Paul Benedict resolved LANG-554.
--------------------------------

Resolution: Fixed

> SystemUtils needs IS_JAVA_1_7 constant
> --------------------------------------
>
> Key: LANG-554
> URL: https://issues.apache.org/jira/browse/LANG-554
> Project: Commons Lang
> Issue Type: Improvement
> Affects Versions: 3.0
> Reporter: Paul Benedict
> Assignee: Paul Benedict
> Priority: Minor
> Fix For: 3.0
>
>
> This constant should exist since Lang 3.0 and JDK 1.7 are both in development.

--
This message is automatically generated by JIRA.
-
You can reply to this email to add a comment to the issue online.

[jira] Created: (LANG-555) SystemUtils needs IS_OS_WINDOWS_7 constant

2009-11-17T21:54:40Z

SystemUtils needs IS_OS_WINDOWS_7 constant
------------------------------------------

Key: LANG-555
URL: https://issues.apache.org/jira/browse/LANG-555
Project: Commons Lang
Issue Type: Improvement
Reporter: Paul Benedict
Assignee: Paul Benedict
Priority: Minor
Fix For: 3.0

--
This message is automatically generated by JIRA.
-
You can reply to this email to add a comment to the issue online.

[jira] Updated: (VALIDATOR-281) Indexed property validation stops on first failed element

2009-11-17T21:03:39Z

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

Lorenzo Dee updated VALIDATOR-281:
----------------------------------

Attachment: Field.java

Here's a simple fix I did. I just modified line 912 (Field.java). Instead of returning, I changed it to break out of the while-loop to continue validating the next element of the indexed list property.

> Indexed property validation stops on first failed element
> ---------------------------------------------------------
>
> Key: VALIDATOR-281
> URL: https://issues.apache.org/jira/browse/VALIDATOR-281
> Project: Commons Validator
> Issue Type: Improvement
> Components: Framework
> Affects Versions: 1.1.4 Release
> Reporter: Lorenzo Dee
> Priority: Trivial
> Attachments: Field.java
>
>
> I'm using Struts 1.2.9 and its validator framework. The validation of an indexed property stops on the first element that fails vaildation. For example, the following list of postal addresses is being validated:
> addr[0].city
> addr[0].state
> addr[0].zip
> addr[1].city
> addr[1].state
> addr[1].zip
> addr[2].city
> addr[2].state
> addr[2].zip
> My validation.xml contains something like:
> <form name="...">
> <field property="city" indexedListProperty="addresses" depends="...">
> . . .
> </field>
> </form>
> When validating the city fields, it would go from addresses[0].city upto addresses[2].city. But when validation fails at addr[0].city, the rest is not being validated anymore (i.e. addr[1].city and addr[2].city are not validated). It would be better if addr[1].city and addr[2].city fields are validated, even if one of them fails.
> Note that this behavior also affects state and zip fields. Say for example, if addr[1].state fails validation, it will no longer continue to validate addr[2].state.

--
This message is automatically generated by JIRA.
-
You can reply to this email to add a comment to the issue online.

[jira] Created: (VALIDATOR-281) Indexed property validation stops on first failed element

2009-11-17T20:53:39Z

Indexed property validation stops on first failed element
---------------------------------------------------------

Key: VALIDATOR-281
URL: https://issues.apache.org/jira/browse/VALIDATOR-281
Project: Commons Validator
Issue Type: Improvement
Components: Framework
Affects Versions: 1.1.4 Release
Reporter: Lorenzo Dee
Priority: Trivial

I'm using Struts 1.2.9 and its validator framework. The validation of an indexed property stops on the first element that fails vaildation. For example, the following list of postal addresses is being validated:

addr[0].city
addr[0].state
addr[0].zip
addr[1].city
addr[1].state
addr[1].zip
addr[2].city
addr[2].state
addr[2].zip

My validation.xml contains something like:

<form name="...">
<field property="city" indexedListProperty="addresses" depends="...">
. . .
</field>
</form>

When validating the city fields, it would go from addresses[0].city upto addresses[2].city. But when validation fails at addr[0].city, the rest is not being validated anymore (i.e. addr[1].city and addr[2].city are not validated). It would be better if addr[1].city and addr[2].city fields are validated, even if one of them fails.

Note that this behavior also affects state and zip fields. Say for example, if addr[1].state fails validation, it will no longer continue to validate addr[2].state.

--
This message is automatically generated by JIRA.
-
You can reply to this email to add a comment to the issue online.

[jira] Updated: (DBCP-305) Use API-specific exception for logging abandoned objects

2009-11-17T13:13:39Z

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

Christopher Schultz updated DBCP-305:
-------------------------------------

Attachment: DBCP-305.diff

Proposed patch to a) use an API-specific exception type and b) include the timestamp in the exception message

The result is that logged exceptions are (hopefully) easier to locate and read in log files.

I used a static inner class to simplify the patch, but you guys are free to split-apart the classes if you choose.

> Use API-specific exception for logging abandoned objects
> --------------------------------------------------------
>
> Key: DBCP-305
> URL: https://issues.apache.org/jira/browse/DBCP-305
> Project: Commons Dbcp
> Issue Type: Improvement
> Reporter: Christopher Schultz
> Priority: Trivial
> Attachments: DBCP-305.diff
>
>
> When a DBCP-managed object (Connection, Statement, etc.) is considered "abandoned", a stack trace is emitted to stdout. Unfortunately, the stack trace is for a simple java.lang.Exception (created in AbandonedTrace.init and AbandonedTrace.setStackTrace) with no message.
> When scanning log files for exceptions, say, like this:
> grep "Exception" my_logfile.log, I simply shows:
> java.lang.Exception
> java.lang.Exception
> java.lang.Exception
> ...
> It would be nice to use a more descriptive exception (for instance, AbandonedObjectException) and/or add a descriptive message to the exception upon creation.
> For example, it would be useful to execute the above command and see:
> org.apache.commons.dbcp.AbandonedObjectException: DBCP object created 2009-11-05 10:15:00 by the following code was never closed
> Having the timestamp and a definite identification of the exception (i.e. the class name) on the same line of log output is preferable IMO.
> Implementation should be trivial; I'd be happy to submit a patch. Also, the format of the logging information isn't part of the API itself, so it shouldn't be a big deal to change it.

--
This message is automatically generated by JIRA.
-
You can reply to this email to add a comment to the issue online.