[jira] Commented: (CONFIGURATION-418) incorrect backslash parsing
[
https://issues.apache.org/jira/browse/CONFIGURATION-418?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=12876140#action_12876140
]
Ricky Martin commented on CONFIGURATION-418:
I understand Oliver, although it is a bit weird. So when you need more than one
consecutive backslash in a comma separated key you need to escape them twice
(one for the general escaping and a second for comma separated parsing).
What I do not know it is why comma separated parsing is performed in a second
phase... That is the final reason for this mess, but I am sure that exceeds me
;-)
Thanks a lot!
incorrect backslash parsing
---
Key: CONFIGURATION-418
URL: https://issues.apache.org/jira/browse/CONFIGURATION-418
Project: Commons Configuration
Issue Type: Bug
Affects Versions: 1.6
Environment: Commons Configuration 1.6
Reporter: Ricky Martin
Assignee: Oliver Heger
Priority: Minor
Attachments: Main.java, PropertyConverter.diff, sample.properties
I am using Commons Configuration (PropertiesConfiguration) and some of my
data are windows shares: \\share1 or \\share2. The problem is the parsing
return different things depending how the keys are defined. For example,
these keys
share=share1
share=share2
are different than:
share=share1, share2
The first one returns two backslashes (\\share1 and \\share2) and the
second returns just one (\share1 and \share2). I think the problem is in
PropertyConverter line 525, cos the backslash is hidden twice when multivalue
parsing is done:
if (c != delimiter c != LIST_ESC_CHAR)
{
// no, also add escape character
token.append(LIST_ESC_CHAR);
}
In my understanding the second condition produces this strange issue and it
should be like this:
if (c != delimiter)
{
// no, also add escape character
token.append(LIST_ESC_CHAR);
}
Check that cos I can be missing something...
TIA
--
This message is automatically generated by JIRA.
-
You can reply to this email to add a comment to the issue online.
[jira] Created: (DBCP-336) Incorect data from data base if connection pool size is minimum (say 1 to 3 )
Incorect data from data base if connection pool size is minimum (say 1 to 3 ) - Key: DBCP-336 URL: https://issues.apache.org/jira/browse/DBCP-336 Project: Commons Dbcp Issue Type: Bug Affects Versions: 1.4 Environment: java on linux and sql server 2005 db on windows Reporter: Rony M Sunny Environment: I have a sp which return data from data base according to a criteria and i put a sleep of 700 millisecond on sp . The connection pool configuration is very minimum compared to data accessing thread, then from multiple java thread i tried to access data for a time period of 30- 60 minute, also i put a query execution time out of 1 second, The result is that Some thread have not get any data from db as there is not much available connection to db in pool and can see it from the exception log , it is OK. But the problem is that after some period time (take 30 - 60 min) data retrieved by threads are incorrect, means data retrieved is, query result of some other thread. My connection pool configuration is here --- property name=maxIdle value=3 description=/ property name=poolInitialSize value=1 description=/ property name=testOnBorrow value=true description=/ property name=maxStmts value=10 description=/ property name=validationQuery value=SELECT 1 description=/ property name=password value=* description=/ property name=url value=jdbc:microsoft:sqlserver://192.168.29.222:1433; DatabaseName=marketsummary description=/ property name=testOnReturn value=true description=/ property name=maxActive value=3 description=/ property name=userId value=*** description=/ property name=minIdle value=3 description=String/ property name=maxWait value=1000 description=/ property name=driver value=com.microsoft.jdbc.sqlserver.SQLServerDriver description=/ -- Please look in to this -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online.
[jira] Created: (MATH-373) StatUtils.sum returns NaN for zero-length arrays
StatUtils.sum returns NaN for zero-length arrays
Key: MATH-373
URL: https://issues.apache.org/jira/browse/MATH-373
Project: Commons Math
Issue Type: Bug
Affects Versions: 2.1
Reporter: Roman Werpachowski
StatUtils.sum returns NaN for zero-length arrays, which is:
1. inconsistent with the mathematical notion of sum: in maths, sum_{i=0}^{N-1}
a_i will be 0 for N=0. In particular, the identity
sum_{i=0}^{k-1} a_i + sum_{i=k}^{N-1} = sum_{i=0}^{N-1}
is broken for k = 0, since NaN + x = NaN, not x.
2. introduces hard to debug erros (returning a NaN is one of the worst forms of
reporting an exceptional condition, as NaNs propagate silently and require
manual tracing during the debugging)
3. enforces special case handling when the user expects that the summed array
can have a zero length.
The correct behaviour is, in my opinion, to return 0.0, not NaN in the above
case.
--
This message is automatically generated by JIRA.
-
You can reply to this email to add a comment to the issue online.
[Wish] Make string WRONG_ORDER_ENDPOINTS_MESSAGE public
Hi, I'm overriding cumulativeProbability and inverseCumulativeProbability on AbstractIntegerDistribution, and was wondering whether the OUT_OF_RANGE_POINT and WRONG_ORDER_ENDPOINTS_MESSAGE strings could be made public, such that the sub classes can have consistent exception messages? Let me know if I should file a ticket. TIA, - Ole
[jira] Updated: (NET-325) FTPSClient does not support pure-ftpd - data connection issues
[ https://issues.apache.org/jira/browse/NET-325?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Wade Poziombka updated NET-325: --- Attachment: commons-net-2.1-ftp.patch Updated patch... fixed small regression issue with using soTimeout instead of __dataTimeout in the _openDataConnection_ method. FTPSClient does not support pure-ftpd - data connection issues -- Key: NET-325 URL: https://issues.apache.org/jira/browse/NET-325 Project: Commons Net Issue Type: Bug Affects Versions: 2.0 Environment: Solaris 10, Windows 2003/XP, Linux (variety). pure-ftpd (1.0.29) running on Linux Reporter: Wade Poziombka Attachments: commons-net-2.1-ftp.patch I do not dare attempt to declare who is right or not. However given the popularity of pure-ftpd, FTPSClient should support it. It seems pure-ftpd expects the SSL handshake before sending the 150 reply to command (e.g., LIST). So it seems that it expects: PASV | PORT 227 etc. LIST handshake 150 ... 226 In Commons Net ftp does the following with the expectation that after the connection is accepted that the server will reply with a 150 ... reply. However, pure-ftpd does not. It only sends the 150 after the handshake is complete. It means that the Socket read times out waiting for the 150. PASV | PORT 227 LIST 150 handshake ... 226 I have patched 2.1 (which includes the NET-313 changes) to support pure-ftpd. -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online.
[jira] Updated: (NET-325) FTPSClient does not support pure-ftpd - data connection issues
[ https://issues.apache.org/jira/browse/NET-325?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Wade Poziombka updated NET-325: --- Attachment: (was: commons-net-2.1-ftp.patch) FTPSClient does not support pure-ftpd - data connection issues -- Key: NET-325 URL: https://issues.apache.org/jira/browse/NET-325 Project: Commons Net Issue Type: Bug Affects Versions: 2.0 Environment: Solaris 10, Windows 2003/XP, Linux (variety). pure-ftpd (1.0.29) running on Linux Reporter: Wade Poziombka Attachments: commons-net-2.1-ftp.patch I do not dare attempt to declare who is right or not. However given the popularity of pure-ftpd, FTPSClient should support it. It seems pure-ftpd expects the SSL handshake before sending the 150 reply to command (e.g., LIST). So it seems that it expects: PASV | PORT 227 etc. LIST handshake 150 ... 226 In Commons Net ftp does the following with the expectation that after the connection is accepted that the server will reply with a 150 ... reply. However, pure-ftpd does not. It only sends the 150 after the handshake is complete. It means that the Socket read times out waiting for the 150. PASV | PORT 227 LIST 150 handshake ... 226 I have patched 2.1 (which includes the NET-313 changes) to support pure-ftpd. -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online.
[math] Re: [Wish] Make string WRONG_ORDER_ENDPOINTS_MESSAGE public
Le 07/06/2010 17:43, Ole Ersoy a écrit : Hi, Hi, First, could you add the commons component name (here math) in bracket in the subject line when posting to this list ? The list is shared among all commons components and this helps filtering. I'm overriding cumulativeProbability and inverseCumulativeProbability on AbstractIntegerDistribution, and was wondering whether the OUT_OF_RANGE_POINT and WRONG_ORDER_ENDPOINTS_MESSAGE strings could be made public, such that the sub classes can have consistent exception messages? Let me know if I should file a ticket. Yes, you should file a ticket in our JIRA system. I think protected would be a better visibility specification than public in that case. Regards Luc TIA, - Ole
[jira] Commented: (CONFIGURATION-418) incorrect backslash parsing
[
https://issues.apache.org/jira/browse/CONFIGURATION-418?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=12876386#action_12876386
]
Oliver Heger commented on CONFIGURATION-418:
Well, to be honest, I am not happy with the current state either. It is pretty
complex and hard to understand. However, given the requirements, I do not know
how we can make it simpler:
* If a property value can contain a list delimiter, there must be a possibility
to escape it.
* Then there must be a way to escape the sequence of an escaped list delimiter.
I am open for suggestions. I am currently updating the user guide, and I hope
this helps a bit to grasp the concept.
incorrect backslash parsing
---
Key: CONFIGURATION-418
URL: https://issues.apache.org/jira/browse/CONFIGURATION-418
Project: Commons Configuration
Issue Type: Bug
Affects Versions: 1.6
Environment: Commons Configuration 1.6
Reporter: Ricky Martin
Assignee: Oliver Heger
Priority: Minor
Attachments: Main.java, PropertyConverter.diff, sample.properties
I am using Commons Configuration (PropertiesConfiguration) and some of my
data are windows shares: \\share1 or \\share2. The problem is the parsing
return different things depending how the keys are defined. For example,
these keys
share=share1
share=share2
are different than:
share=share1, share2
The first one returns two backslashes (\\share1 and \\share2) and the
second returns just one (\share1 and \share2). I think the problem is in
PropertyConverter line 525, cos the backslash is hidden twice when multivalue
parsing is done:
if (c != delimiter c != LIST_ESC_CHAR)
{
// no, also add escape character
token.append(LIST_ESC_CHAR);
}
In my understanding the second condition produces this strange issue and it
should be like this:
if (c != delimiter)
{
// no, also add escape character
token.append(LIST_ESC_CHAR);
}
Check that cos I can be missing something...
TIA
--
This message is automatically generated by JIRA.
-
You can reply to this email to add a comment to the issue online.
[jira] Commented: (CONFIGURATION-418) incorrect backslash parsing
[
https://issues.apache.org/jira/browse/CONFIGURATION-418?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=12876392#action_12876392
]
Sebb commented on CONFIGURATION-418:
The escaping should not depend on whether a list delimiter is present.
Therefore the parsing needs to be done in a single pass, otherwise there will
always be an ambiguity.
If parsing is done in a single pass, the code knows if the comma has been
escaped or not.
The following are the possibilities - should be easy enough to parse:
{noformat}
\\ = \
\, = , but not a list delimiter
\\, = \ followed by list delimiter
\\\, = \, (not a list delimiter)
{noformat}
It's then trivial to encode property definitions:
* escape any backslashes
* escape any list delimiters that are not supposed to be list delimiters.
incorrect backslash parsing
---
Key: CONFIGURATION-418
URL: https://issues.apache.org/jira/browse/CONFIGURATION-418
Project: Commons Configuration
Issue Type: Bug
Affects Versions: 1.6
Environment: Commons Configuration 1.6
Reporter: Ricky Martin
Assignee: Oliver Heger
Priority: Minor
Attachments: Main.java, PropertyConverter.diff, sample.properties
I am using Commons Configuration (PropertiesConfiguration) and some of my
data are windows shares: \\share1 or \\share2. The problem is the parsing
return different things depending how the keys are defined. For example,
these keys
share=share1
share=share2
are different than:
share=share1, share2
The first one returns two backslashes (\\share1 and \\share2) and the
second returns just one (\share1 and \share2). I think the problem is in
PropertyConverter line 525, cos the backslash is hidden twice when multivalue
parsing is done:
if (c != delimiter c != LIST_ESC_CHAR)
{
// no, also add escape character
token.append(LIST_ESC_CHAR);
}
In my understanding the second condition produces this strange issue and it
should be like this:
if (c != delimiter)
{
// no, also add escape character
token.append(LIST_ESC_CHAR);
}
Check that cos I can be missing something...
TIA
--
This message is automatically generated by JIRA.
-
You can reply to this email to add a comment to the issue online.
[jira] Updated: (LANG-462) FastDateFormat supports parse
[ https://issues.apache.org/jira/browse/LANG-462?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Charles Honton updated LANG-462: Attachment: lang462.patch Separate FastDateParser class which will supports the parse methods. I'm not sure whether this code is best separate or merged into FastDateFormat FastDateFormat supports parse - Key: LANG-462 URL: https://issues.apache.org/jira/browse/LANG-462 Project: Commons Lang Issue Type: New Feature Components: lang.time.* Reporter: Franz Wong Fix For: 3.1 Attachments: lang462.patch Currently FastDateFormat only supports formatting the ISO8601 time zone, however, it doesn't support parsing such string to Date. -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online.
[jira] Updated: (LANG-462) FastDateFormat supports parse
[ https://issues.apache.org/jira/browse/LANG-462?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Charles Honton updated LANG-462: Attachment: UseFormatCache.patch Have FastDateFormat use FormatCache developed for FastDateParser. Drawback: timeZoneForced concept removed. I'm not sure what advantage that feature offered. 1. It was under-documented what it did and how it worked. 2. Easy to get same functionality by using format(cal.getTime()) instead of format(cal) My understanding is that Version 3 is not necessarily a drop-in replacement for prior versions. FastDateFormat supports parse - Key: LANG-462 URL: https://issues.apache.org/jira/browse/LANG-462 Project: Commons Lang Issue Type: New Feature Components: lang.time.* Reporter: Franz Wong Fix For: 3.1 Attachments: lang462.patch, UseFormatCache.patch Currently FastDateFormat only supports formatting the ISO8601 time zone, however, it doesn't support parsing such string to Date. -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online.
[jira] Commented: (MATH-373) StatUtils.sum returns NaN for zero-length arrays
[
https://issues.apache.org/jira/browse/MATH-373?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=12876512#action_12876512
]
Bill Barker commented on MATH-373:
--
I agree with the reasoning here, and we should do it this way in 3.0. However
it is an incompatible change to do in a point release, so I'm going to wait for
more feed back from other developers before I make any changes to the current
code.
I'm thinking that adding a method to AbstractUnivariateStatistic that looks
like:
protected boolean test( final double[] values, final int begin, final int
length, final boolean allowEmpty)
that would have the test:
if(length == 0 !allowEmpty)
return false;
The current test method can call the new one with allowEmpty=false for
backwards compatibility. Then we can decide on which statistics should have a
zero value on the empty set.
StatUtils.sum returns NaN for zero-length arrays
Key: MATH-373
URL: https://issues.apache.org/jira/browse/MATH-373
Project: Commons Math
Issue Type: Bug
Affects Versions: 2.1
Reporter: Roman Werpachowski
StatUtils.sum returns NaN for zero-length arrays, which is:
1. inconsistent with the mathematical notion of sum: in maths,
sum_{i=0}^{N-1} a_i will be 0 for N=0. In particular, the identity
sum_{i=0}^{k-1} a_i + sum_{i=k}^{N-1} = sum_{i=0}^{N-1}
is broken for k = 0, since NaN + x = NaN, not x.
2. introduces hard to debug erros (returning a NaN is one of the worst forms
of reporting an exceptional condition, as NaNs propagate silently and require
manual tracing during the debugging)
3. enforces special case handling when the user expects that the summed
array can have a zero length.
The correct behaviour is, in my opinion, to return 0.0, not NaN in the above
case.
--
This message is automatically generated by JIRA.
-
You can reply to this email to add a comment to the issue online.
[jira] Commented: (CONFIGURATION-418) incorrect backslash parsing
[
https://issues.apache.org/jira/browse/CONFIGURATION-418?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=12876555#action_12876555
]
Oliver Heger commented on CONFIGURATION-418:
Just to make sure I understand you correctly: With parsing in two passes you
mean that the presence of a list delimiter influences the escaping algorithm,
so that list elements may have to be defined in a different way when they are
put on a single line or on multiple lines, right?
Yes, I agree, this should be made consistent. I don't know why it is currently
implemented this way, but the code is there probably for a long time now. So I
wonder whether we should change the parsing in a minor release because this
impacts the way certain properties have to be defined and might break existing
applications. Therefore I tend to close this ticket (a bug actually has been
fixed) and open a new one, targeted to a 2.0 release, with the goal to rework
the parsing algorithm. WDYT?
incorrect backslash parsing
---
Key: CONFIGURATION-418
URL: https://issues.apache.org/jira/browse/CONFIGURATION-418
Project: Commons Configuration
Issue Type: Bug
Affects Versions: 1.6
Environment: Commons Configuration 1.6
Reporter: Ricky Martin
Assignee: Oliver Heger
Priority: Minor
Attachments: Main.java, PropertyConverter.diff, sample.properties
I am using Commons Configuration (PropertiesConfiguration) and some of my
data are windows shares: \\share1 or \\share2. The problem is the parsing
return different things depending how the keys are defined. For example,
these keys
share=share1
share=share2
are different than:
share=share1, share2
The first one returns two backslashes (\\share1 and \\share2) and the
second returns just one (\share1 and \share2). I think the problem is in
PropertyConverter line 525, cos the backslash is hidden twice when multivalue
parsing is done:
if (c != delimiter c != LIST_ESC_CHAR)
{
// no, also add escape character
token.append(LIST_ESC_CHAR);
}
In my understanding the second condition produces this strange issue and it
should be like this:
if (c != delimiter)
{
// no, also add escape character
token.append(LIST_ESC_CHAR);
}
Check that cos I can be missing something...
TIA
--
This message is automatically generated by JIRA.
-
You can reply to this email to add a comment to the issue online.
