[jira] Closed: (CLI-188) Adding the another hyphen code 96.
[
https://issues.apache.org/jira/browse/CLI-188?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Henri Yandell closed CLI-188.
-
Resolution: Won't Fix
Agreed - resolving as wontfix.
> Adding the another hyphen code 96.
> --
>
> Key: CLI-188
> URL: https://issues.apache.org/jira/browse/CLI-188
> Project: Commons CLI
> Issue Type: Improvement
> Components: Parser
>Affects Versions: 1.0, 1.1, 1.2
>Reporter: Grzegorz Solecki
>Priority: Trivial
> Fix For: 1.3
>
> Attachments: TwoDifferentHyphens.txt
>
>
> In the class Parser (rev 680644) close to line 190 there is code:
> \\
> \\
> {code:title=Parser.java}
> // the value is an option
> else if (t.startsWith("-"))
> {
> {code}
> This line recognizes hyphen like -
> But sometimes (when someone has to work with MS Word Docs) this hyphen - can
> be used instead of -.
> So I would like to suggest just adding a simple piece of code like:
> \\
> \\
> {code:title=Parser.java}
> // the value is an option
> else if (t.startsWith("-") || t.startsWith("-"))
> {
> {code}
> or try to throw an exception like "Option expected not " or "unexpected
> argument".
--
This message is automatically generated by JIRA.
-
You can reply to this email to add a comment to the issue online.
[jira] Closed: (CLI-191) Coding error: OptionGroup.setSelected causes java.lang.NullPointerException
[
https://issues.apache.org/jira/browse/CLI-191?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Henri Yandell closed CLI-191.
-
Resolution: Fixed
Per report this is already fixed - resolving.
> Coding error: OptionGroup.setSelected causes java.lang.NullPointerException
> ---
>
> Key: CLI-191
> URL: https://issues.apache.org/jira/browse/CLI-191
> Project: Commons CLI
> Issue Type: Bug
>Affects Versions: 1.2
>Reporter: gg
> Fix For: 1.3
>
>
> Code snippet from OptionGroup.setSelected(Option option):
> ...
> if (selected == null || selected.equals(option.getOpt()))
> {
> selected = option.getOpt();
> }
> else
> {
> throw new AlreadySelectedException(this, option);
> }
> ...
> When parameter option is "null" to reset the selected option,
> selected.equals(option.getOpt()) will obviously fail.
> Issue is already fixed in the head revision of 1.3.
--
This message is automatically generated by JIRA.
-
You can reply to this email to add a comment to the issue online.
[jira] Updated: (LANG-596) StrSubstitutor should also handle the default properties of a java.util.Properties class
[
https://issues.apache.org/jira/browse/LANG-596?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Henri Yandell updated LANG-596:
---
Fix Version/s: 3.1
Sounds good - assigning to 3.1. Needs code/test patch.
> StrSubstitutor should also handle the default properties of a
> java.util.Properties class
>
>
> Key: LANG-596
> URL: https://issues.apache.org/jira/browse/LANG-596
> Project: Commons Lang
> Issue Type: Bug
> Components: lang.text.*
>Affects Versions: 2.5
>Reporter: Ulrich Voigt
>Priority: Minor
> Fix For: 3.1
>
> Original Estimate: 0.5h
> Remaining Estimate: 0.5h
>
> The following program show a problem with a shortcoming of the
> java.util.Properties class.
> The default properties are not substituted by the StrSubstitutor.
> {code:title=StrSubstTest.java|borderStyle=solid}
> import org.apache.commons.lang.text.StrSubstitutor;
> public class StrSubstTest
> {
> public static void main(String[] args)
> {
> String org = "${doesnotwork}";
> System.setProperty("doesnotwork", "It work's!");
> // create a new Poperties object with the System.getProperties as
> default
> Properties props = new Properties(System.getProperties());
> String subst = StrSubstitutor.replace(org, props);
> // is ${doesnotwork} substituted?
> System.out.println(subst);
> }
> }
> {code}
> The following method could be added to the StrSubstitutor class to fix this
> problem in an easy way:
> {code:borderStyle=solid}
> /**
> * Replaces all the occurrences of variables in the given source object
> with their matching
> * values from the properties.
> *
> * @param source the source text containing the variables to substitute,
> null returns null
> * @param properties the properties with values, may be null
> * @return the result of the replace operation
> */
> public static String replace(Object source, Properties valueProperties)
> {
> if (valueProperties == null) {
> return source;
> }
> Map valueMap = new HashMap();
> Enumeration propNames = valueProperties.propertyNames();
> while (propNames.hasMoreElements())
> {
> String propName = (String)propNames.nextElement();
> String propValue = valueProperties.getProperty(propName);
> valueMap.put(propName, propValue);
> }
> return StrSubstitutor.replace(source, valueMap);
> }
> {code}
--
This message is automatically generated by JIRA.
-
You can reply to this email to add a comment to the issue online.
[jira] Closed: (LANG-490) Note to rewrite package.html's before release.
[ https://issues.apache.org/jira/browse/LANG-490?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Henri Yandell closed LANG-490. -- Resolution: Fixed Done. Not a lot to change in fact. > Note to rewrite package.html's before release. > -- > > Key: LANG-490 > URL: https://issues.apache.org/jira/browse/LANG-490 > Project: Commons Lang > Issue Type: Task > Components: General >Reporter: Henri Yandell > Fix For: 3.0 > > > Lots of deletions etc mean the package.htmls are probably going to get > incorrect. -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online.
[jira] Created: (IO-230) DirectoryWalker needs to use generics to avoid compilation warnings
DirectoryWalker needs to use generics to avoid compilation warnings
---
Key: IO-230
URL: https://issues.apache.org/jira/browse/IO-230
Project: Commons IO
Issue Type: Improvement
Components: Utilities
Affects Versions: 1.4
Reporter: Benoit Sigoure
Priority: Minor
When overriding methods such as {{handleFile}}, a generic {{Collection}} object
is passed in argument. One is expected to add something to it, such as in this
excerpt from [{{DirectoryWalker}}'s own
javadoc|http://commons.apache.org/io/api-release/org/apache/commons/io/DirectoryWalker.html]:
{code}
protected void handleFile(File file, int depth, Collection results) {
[...]
results.add(file); // This lines triggers a warning.
}
{code}
This code triggers a {{warning: [unchecked] unchecked call to add(E) as a
member of the raw type java.util.Collection}}. I believe the right fix is to
change {{DirectoryWalker}} to be parameterized by a type {{T}} so that the
signature of {{handleFile}} (and other similar methods) can be changed to
receive a {{Collection}} in argument.
--
This message is automatically generated by JIRA.
-
You can reply to this email to add a comment to the issue online.
[jira] Commented: (LANG-482) Enhance StrSubstitutor to support nested ${var-${subvr}} expansion
[
https://issues.apache.org/jira/browse/LANG-482?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=12840022#action_12840022
]
Rob Walker commented on LANG-482:
-
Sounds good Paul, thanks for clarifying
- Rob
> Enhance StrSubstitutor to support nested ${var-${subvr}} expansion
> --
>
> Key: LANG-482
> URL: https://issues.apache.org/jira/browse/LANG-482
> Project: Commons Lang
> Issue Type: Improvement
> Components: lang.text.*
>Reporter: Rob Walker
>Priority: Minor
> Fix For: 3.1
>
> Attachments: StrSubstitutor.java.nested.patch
>
>
> t would be really handy of StrSubstitutor could support nested variable
> interpolation:
> org.osgi.framework.system.packages=org.osgi.framework; version=1.4.0, \
> org.osgi.service.packageadmin; version=1.2.0, \
> org.osgi.service.startlevel; version=1.1.0, \
> org.osgi.service.url; version=1.0.0, \
> org.osgi.util.tracker; version=1.3.3 \
> ${jre-${java.specification.version}}
> The process being to expand innermost variable references first and work
> outwards - this allows for very advance config, such as the above, which can
> dynamically detect the Java version and expand a JRE version specific
> property into the property being defined.
> Looking at the implementation, it seems it might be a fairly straightforward
> enhancement to:
> private int substitute(StrBuilder buf, int offset, int length, List
> priorVariables)
> The code already has the cyclic map in place.
> I already have code that achieves this within Apache Felix, so I will see if
> I can retro-fit a similar model to the above and if so submit a patch.
--
This message is automatically generated by JIRA.
-
You can reply to this email to add a comment to the issue online.
[jira] Created: (SANSELAN-36) Sanselan tests fail on Windows
Sanselan tests fail on Windows
--
Key: SANSELAN-36
URL: https://issues.apache.org/jira/browse/SANSELAN-36
Project: Commons Sanselan
Issue Type: Test
Reporter: Niall Pemberton
Priority: Minor
A number of the Sanselan tests fail on windows - all related to the use of the
following code with file paths:
{code}
"...".replaceAll("", System.getProperty("file.separator")
{code}
The problem is on windows the file separator is a "back slash" character which
needs to be escaped in regular expressions.
This affects:
* SanselanTestConstants (causes ExceptionIntializedError because the
static PHIL_HARVEY_TEST_IMAGE_FOLDER fails when its being initialized with a
StringIndexOutOfBoundsException)
* SanselanGuessFormatTest fails in testGuess_all() and testGuess_unknown()
throwing StringIndexOutOfBoundsException
* PngMultipleRoundtripTest fails in test() throwing
StringIndexOutOfBoundsException
--
This message is automatically generated by JIRA.
-
You can reply to this email to add a comment to the issue online.
[jira] Commented: (LANG-482) Enhance StrSubstitutor to support nested ${var-${subvr}} expansion
[
https://issues.apache.org/jira/browse/LANG-482?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=12839882#action_12839882
]
Paul Benedict commented on LANG-482:
Rob, you may have missed my edit. I was pointing out this should be a toggled
feature -- some people may want to produce template based outputs that include
${...}, which means the replacement shouldn't be replaced.
> Enhance StrSubstitutor to support nested ${var-${subvr}} expansion
> --
>
> Key: LANG-482
> URL: https://issues.apache.org/jira/browse/LANG-482
> Project: Commons Lang
> Issue Type: Improvement
> Components: lang.text.*
>Reporter: Rob Walker
>Priority: Minor
> Fix For: 3.1
>
> Attachments: StrSubstitutor.java.nested.patch
>
>
> t would be really handy of StrSubstitutor could support nested variable
> interpolation:
> org.osgi.framework.system.packages=org.osgi.framework; version=1.4.0, \
> org.osgi.service.packageadmin; version=1.2.0, \
> org.osgi.service.startlevel; version=1.1.0, \
> org.osgi.service.url; version=1.0.0, \
> org.osgi.util.tracker; version=1.3.3 \
> ${jre-${java.specification.version}}
> The process being to expand innermost variable references first and work
> outwards - this allows for very advance config, such as the above, which can
> dynamically detect the Java version and expand a JRE version specific
> property into the property being defined.
> Looking at the implementation, it seems it might be a fairly straightforward
> enhancement to:
> private int substitute(StrBuilder buf, int offset, int length, List
> priorVariables)
> The code already has the cyclic map in place.
> I already have code that achieves this within Apache Felix, so I will see if
> I can retro-fit a similar model to the above and if so submit a patch.
--
This message is automatically generated by JIRA.
-
You can reply to this email to add a comment to the issue online.
[jira] Created: (IO-229) Convert AndFileFilter Constructor to Use Varargs
Convert AndFileFilter Constructor to Use Varargs
Key: IO-229
URL: https://issues.apache.org/jira/browse/IO-229
Project: Commons IO
Issue Type: Improvement
Components: Filters
Affects Versions: 2.0
Environment: Java 1.5+
Reporter: Michael Wooten
Priority: Minor
Fix For: 2.0
I suggest converting the AndFileFilter(IOFileFilter filter1, IOFileFilter
filter2) constructor to use varargs and instead have the signature
AndFileFilter(IOFileFilter... filters). The benefit is that new AndFileFilters
could be created without having to create a list or limit the initial number of
filters to two.
Ex:
IOFileFilter hiddenNonEmptyTextFileFilter = new
AndFileFilter(HiddenFileFilter.HIDDEN, EmptyFileFilter.NOT_EMPTY, new
SuffixFileFilter(".txt"));
--
This message is automatically generated by JIRA.
-
You can reply to this email to add a comment to the issue online.
[jira] Commented: (CONFIGURATION-409) Key containing escapedDelimiter does not save() properly
[
https://issues.apache.org/jira/browse/CONFIGURATION-409?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=12839851#action_12839851
]
Oliver Heger commented on CONFIGURATION-409:
You are right: this is a bug. Thank you for reporting this. I hope I manage to
find some time in the next days to have a look.
> Key containing escapedDelimiter does not save() properly
>
>
> Key: CONFIGURATION-409
> URL: https://issues.apache.org/jira/browse/CONFIGURATION-409
> Project: Commons Configuration
> Issue Type: Bug
> Components: Expression engine
>Affects Versions: 1.6
>Reporter: Andrew Cooper
>
> It seems that a key containing the escapedDelimiter is stored without the
> delimiter and the escape is not recreated when saving the configuration.
>
> {code:title=test.java}
> HierarchicalINIConfiguration inicfg = new HierarchicalINIConfiguration();
> inicfg.setProperty( "Andrew L.. Cooper.first", "Andrew" );
> inicfg.setProperty( "Andrew L.. Cooper.last", "Cooper" );
> inicfg.setProperty( "Andrew L.. Cooper.mail", "andrew.coo...@example.com" );
> inicfg.save( System.out );
> System.out.println( inicfg.get( "Andrew L..Cooper.mail" );
> {code}
> {code:title=Expected Output}
> [Andrew L. Cooper]
> first = Andrew
> last = Cooper
> mail = andrew.coo...@example.com
> andrew.coo...@example.com
> {code}
> {code:title=Actual Output}
> [Andrew L. Cooper]
> andrew.coo...@example.com
> {code}
--
This message is automatically generated by JIRA.
-
You can reply to this email to add a comment to the issue online.
[jira] Commented: (JXPATH-129) MethodLookupUtils#matchType uses TypeUtils#canConvert which causes "Ambiguous method call" exception.
[
https://issues.apache.org/jira/browse/JXPATH-129?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=12839842#action_12839842
]
Robert Ross commented on JXPATH-129:
Yes, you are forgetting the standard method of invoking static methods:
http://commons.apache.org/jxpath/users-guide.html#Standard_Extension_Functions.
I was using function call JXpath syntax like this:
"com.dsci.util.FormatUtils.isoDateFormat(date)"
Where date is a Calendar instance or date is a Date instance.
This isn't just observational either. I traced this by stepping all the way
into the code until I could see where the Calendar was converted to a Date and
then the error was thrown. This is also the same class file where the spelling
errors were noticed. This bug was logged about a year ago so perhaps it has
been fixed already? I'm not in a position to test it at this point.
Robert A. Ross
Senior Software Developer
DSCI Inc.
609.509.5139 - Mobile
609.702.8114 - Home
> MethodLookupUtils#matchType uses TypeUtils#canConvert which causes "Ambiguous
> method call" exception.
> -
>
> Key: JXPATH-129
> URL: https://issues.apache.org/jira/browse/JXPATH-129
> Project: Commons JXPath
> Issue Type: Bug
> Environment: Not relevant.
>Reporter: Robert Ross
> Fix For: 1.4
>
> Attachments: MethodLookupTest.java
>
>
> MethodLookupUtils#matchParameterTypes calls MethodUtils#matchType.
> MethodLookupUtils#matchType includes this:
> if (TypeUtils.canConvert(object, expected)) {
> return APPROXIMATE_MATCH;
> }
> This goes through a whole process of attempting to convert types using
> JXPath-specific conversion routines. However, this is not valid logic when
> attempting to find matching Methods since overloaded functions with
> "convertable" parameters would still have different function signatures.
> An example:
> abstract class ExampleClass
> {
> static final String formatISO(Calendar calendar) { return ""};
> static final String formatISO(Date date) { return ""};
> }
> If referenced from JXPath with "ExampleClass.formatISO(pathToDateObject)",
> these two functions would trigger JXPathException("lookupMethod() Ambiguous
> method call: " + name) because apparently TypeUtils is able to convert a
> Calendar to a Date and vice-versa.
> When attempting to retrieve a function via signature, is it not irrelevant
> whether JXPath is able to convert a parameter's type or not? Is there a way
> to change this behavior or provide a way to toggle this behavior similar to
> the setLenient() method.
> Also, the word "Ambiguous" is spelled incorrectly as "Ambigous" three times
> in MethodLookupUtils.
--
This message is automatically generated by JIRA.
-
You can reply to this email to add a comment to the issue online.
[jira] Commented: (MATH-282) ChiSquaredDistributionImpl.cumulativeProbability > 1
[ https://issues.apache.org/jira/browse/MATH-282?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=12839839#action_12839839 ] Phil Steitz commented on MATH-282: -- Thanks, Luc! Here is the perhaps strange logic explaining the odd exception nesting that you pointed out. When a cumulativeProbability function returns NaN in the context of estimating inverse cum, the immediate exception is really a bad-value-returned exception, not a FunctionEvaluationException - there is no exception encountered evaluating the function, it just returns a bad value - so I code it as MathException. The exception that the caller gets is FunctionEvaluationException, because there is in fact an error evaluating the inverse cum. Wrapped inside is the MathException with the message indicating that NaN was returned by a cum activation. I guess it comes down to how we view FunctionEvaluationException and in particular is it appropriate to throw when NaN is returned by a method that logically should not return NaNs. Thinking some more about this, I think so, so I will change the patch to throw FunctionEvaluationException in the first incidence. Thanks again for looking at this carefully. I am glad I got the translations right - the one I was worried about was as much English as French - "diverge to NaN" makes me cringe a little ;) > ChiSquaredDistributionImpl.cumulativeProbability > 1 > > > Key: MATH-282 > URL: https://issues.apache.org/jira/browse/MATH-282 > Project: Commons Math > Issue Type: Bug >Affects Versions: 1.0, 1.1, 1.2, 2.0 > Environment: called from Scala code >Reporter: Adam Kiezun >Assignee: Phil Steitz > Fix For: 2.1 > > Attachments: distributions.patch, math-282.patch > > > Calling > new ChiSquaredDistributionImpl(1.0).cumulativeProbability(66.41528551683048) > returns 1.004, which is bogus (should never be > 1) -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online.
[jira] Commented: (LANG-482) Enhance StrSubstitutor to support nested ${var-${subvr}} expansion
[
https://issues.apache.org/jira/browse/LANG-482?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=12839833#action_12839833
]
Rob Walker commented on LANG-482:
-
We find them useful and use them extensively. If others have objections to them
or don't find them useful, it's not really a big deal for us. We've got this
work applied to our locally customised version anyhow, so we'll just keep
re-applying it whenever we upgrade the root Apache version.
> Enhance StrSubstitutor to support nested ${var-${subvr}} expansion
> --
>
> Key: LANG-482
> URL: https://issues.apache.org/jira/browse/LANG-482
> Project: Commons Lang
> Issue Type: Improvement
> Components: lang.text.*
>Reporter: Rob Walker
>Priority: Minor
> Fix For: 3.1
>
> Attachments: StrSubstitutor.java.nested.patch
>
>
> t would be really handy of StrSubstitutor could support nested variable
> interpolation:
> org.osgi.framework.system.packages=org.osgi.framework; version=1.4.0, \
> org.osgi.service.packageadmin; version=1.2.0, \
> org.osgi.service.startlevel; version=1.1.0, \
> org.osgi.service.url; version=1.0.0, \
> org.osgi.util.tracker; version=1.3.3 \
> ${jre-${java.specification.version}}
> The process being to expand innermost variable references first and work
> outwards - this allows for very advance config, such as the above, which can
> dynamically detect the Java version and expand a JRE version specific
> property into the property being defined.
> Looking at the implementation, it seems it might be a fairly straightforward
> enhancement to:
> private int substitute(StrBuilder buf, int offset, int length, List
> priorVariables)
> The code already has the cyclic map in place.
> I already have code that achieves this within Apache Felix, so I will see if
> I can retro-fit a similar model to the above and if so submit a patch.
--
This message is automatically generated by JIRA.
-
You can reply to this email to add a comment to the issue online.
[jira] Resolved: (MATH-347) Brent solver shouldn't need strict ordering of min, max and initial
[ https://issues.apache.org/jira/browse/MATH-347?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Luc Maisonobe resolved MATH-347. Resolution: Fixed Fixed in subversion repository as of r917668. Thanks for reporting the issue > Brent solver shouldn't need strict ordering of min, max and initial > --- > > Key: MATH-347 > URL: https://issues.apache.org/jira/browse/MATH-347 > Project: Commons Math > Issue Type: Bug >Affects Versions: 2.0 >Reporter: Volkan Aktas > > The "solve(final UnivariateRealFunction f, final double min, final double > max, final double initial)" function calls verifySequence() which enforces a > strict ordering of min, max and initial parameters. I can't see why that is > necessary - the rest of solve() seems to be able to handle "initial == min" > and "initial == min" cases just fine. In fact, the JavaDoc suggests setting > initial to min when not known but that is not possible at the moment. -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online.
[jira] Commented: (MATH-282) ChiSquaredDistributionImpl.cumulativeProbability > 1
[ https://issues.apache.org/jira/browse/MATH-282?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=12839809#action_12839809 ] Luc Maisonobe commented on MATH-282: This looks fine to me (congrats for the error messages translations). I am a little puzzled by the MathException thrown in some methods to be caught in the same method and wrapped in a FunctionEvaluationException. Could the MathException be a FunctionEvaluationException from the start (even if other MathException can be thrown and need to be wrapped by themselves) ? > ChiSquaredDistributionImpl.cumulativeProbability > 1 > > > Key: MATH-282 > URL: https://issues.apache.org/jira/browse/MATH-282 > Project: Commons Math > Issue Type: Bug >Affects Versions: 1.0, 1.1, 1.2, 2.0 > Environment: called from Scala code >Reporter: Adam Kiezun >Assignee: Phil Steitz > Fix For: 2.1 > > Attachments: distributions.patch, math-282.patch > > > Calling > new ChiSquaredDistributionImpl(1.0).cumulativeProbability(66.41528551683048) > returns 1.004, which is bogus (should never be > 1) -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online.
[jira] Created: (CONFIGURATION-409) Key containing escapedDelimiter does not save() properly
Key containing escapedDelimiter does not save() properly
Key: CONFIGURATION-409
URL: https://issues.apache.org/jira/browse/CONFIGURATION-409
Project: Commons Configuration
Issue Type: Bug
Components: Expression engine
Affects Versions: 1.6
Reporter: Andrew Cooper
It seems that a key containing the escapedDelimiter is stored without the
delimiter and the escape is not recreated when saving the configuration.
{code:title=test.java}
HierarchicalINIConfiguration inicfg = new HierarchicalINIConfiguration();
inicfg.setProperty( "Andrew L.. Cooper.first", "Andrew" );
inicfg.setProperty( "Andrew L.. Cooper.last", "Cooper" );
inicfg.setProperty( "Andrew L.. Cooper.mail", "andrew.coo...@example.com" );
inicfg.save( System.out );
System.out.println( inicfg.get( "Andrew L..Cooper.mail" );
{code}
{code:title=Expected Output}
[Andrew L. Cooper]
first = Andrew
last = Cooper
mail = andrew.coo...@example.com
andrew.coo...@example.com
{code}
{code:title=Actual Output}
[Andrew L. Cooper]
andrew.coo...@example.com
{code}
--
This message is automatically generated by JIRA.
-
You can reply to this email to add a comment to the issue online.
[jira] Commented: (JXPATH-129) MethodLookupUtils#matchType uses TypeUtils#canConvert which causes "Ambiguous method call" exception.
[
https://issues.apache.org/jira/browse/JXPATH-129?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=12839747#action_12839747
]
Matt Benson commented on JXPATH-129:
My test, if you would review the attachment, differs from your example in two
respects only: my methods (a) are not declared as final (which in my
understanding is moot in the case of a static method), and (b) are called
"toString" rather than "formatISO". Are you suggesting that it is one of these
two items causing me to get different results than you? If not, again, I would
ask you to tell me what I have done wrong that stops me from getting your
results. Was I correct to assume that you were speaking of registering your
ExampleClass as a provider of extension functions, or have I somehow forgotten
some other mechanism by which you are attempting to invoke these methods?
> MethodLookupUtils#matchType uses TypeUtils#canConvert which causes "Ambiguous
> method call" exception.
> -
>
> Key: JXPATH-129
> URL: https://issues.apache.org/jira/browse/JXPATH-129
> Project: Commons JXPath
> Issue Type: Bug
> Environment: Not relevant.
>Reporter: Robert Ross
> Fix For: 1.4
>
> Attachments: MethodLookupTest.java
>
>
> MethodLookupUtils#matchParameterTypes calls MethodUtils#matchType.
> MethodLookupUtils#matchType includes this:
> if (TypeUtils.canConvert(object, expected)) {
> return APPROXIMATE_MATCH;
> }
> This goes through a whole process of attempting to convert types using
> JXPath-specific conversion routines. However, this is not valid logic when
> attempting to find matching Methods since overloaded functions with
> "convertable" parameters would still have different function signatures.
> An example:
> abstract class ExampleClass
> {
> static final String formatISO(Calendar calendar) { return ""};
> static final String formatISO(Date date) { return ""};
> }
> If referenced from JXPath with "ExampleClass.formatISO(pathToDateObject)",
> these two functions would trigger JXPathException("lookupMethod() Ambiguous
> method call: " + name) because apparently TypeUtils is able to convert a
> Calendar to a Date and vice-versa.
> When attempting to retrieve a function via signature, is it not irrelevant
> whether JXPath is able to convert a parameter's type or not? Is there a way
> to change this behavior or provide a way to toggle this behavior similar to
> the setLenient() method.
> Also, the word "Ambiguous" is spelled incorrectly as "Ambigous" three times
> in MethodLookupUtils.
--
This message is automatically generated by JIRA.
-
You can reply to this email to add a comment to the issue online.
[jira] Updated: (DBCP-219) how to kill a connection from the connection pool without shutting down the connection pool
[ https://issues.apache.org/jira/browse/DBCP-219?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Gustavo Huff Mauch updated DBCP-219: Comment: was deleted (was: [FÉRIAS] - Estou de férias! Volto dia 01/03. Assuntos urgentes tratar com Cléo (ramal 1112). Periodo de afastamento Inicio: 13/2/2010 Termino: 27/2/2010 -- DATACOM - Mauch DATACOM Av. Franca, 725 - Porto Alegre, RS - 90230-220 DDR: +55 51 3358 0100 FAX: +55 51 3358 0101 site: http://www.datacom.ind.br e-mail: ) > how to kill a connection from the connection pool without shutting down the > connection pool > --- > > Key: DBCP-219 > URL: https://issues.apache.org/jira/browse/DBCP-219 > Project: Commons Dbcp > Issue Type: New Feature >Affects Versions: 2.0 > Environment: Windows, Unix >Reporter: Bill Liu > Fix For: 2.0 > > > Hi: > This is really not a bug but probably a desired feature and something I am > not aware of. > We use the Apache connection pool in a Servlet environment. We need the > feature to kill or close a connection forcefully when it is being used by a > servlet. The reason can be various: an evil servlet that holds a connection > forever, db issue, network issue, etc. How can we do that? I notice that > datasource.getConnection() always returns a new connection. How do we keep > track of connections that are being used so we can close them if needed? > Currently we can only kill one at the database side by a DBA. > Should we write a a util to keep track of connection objects that are > borrowed by clients? -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online.
[jira] Issue Comment Edited: (LANG-482) Enhance StrSubstitutor to support nested ${var-${subvr}} expansion
[
https://issues.apache.org/jira/browse/LANG-482?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=12839712#action_12839712
]
Paul Benedict edited comment on LANG-482 at 3/1/10 4:17 PM:
I am not a fan of substitution variables that become substitution variables. It
sounds closer to a pre-compiler. Technologies like Maven, Spring, and JSP/JSF
do not support this and, likewise, I vote not to apply this -- unless it is an
option that can be toggled.
was (Author: paul4christ79):
I am not a fan of substitution variables that become substitution
variables. It sounds closer to a pre-compiler. Technologies like Maven, Spring,
and JSP/JSF do not support this and, likewise, I vote not to apply this.
> Enhance StrSubstitutor to support nested ${var-${subvr}} expansion
> --
>
> Key: LANG-482
> URL: https://issues.apache.org/jira/browse/LANG-482
> Project: Commons Lang
> Issue Type: Improvement
> Components: lang.text.*
>Reporter: Rob Walker
>Priority: Minor
> Fix For: 3.1
>
> Attachments: StrSubstitutor.java.nested.patch
>
>
> t would be really handy of StrSubstitutor could support nested variable
> interpolation:
> org.osgi.framework.system.packages=org.osgi.framework; version=1.4.0, \
> org.osgi.service.packageadmin; version=1.2.0, \
> org.osgi.service.startlevel; version=1.1.0, \
> org.osgi.service.url; version=1.0.0, \
> org.osgi.util.tracker; version=1.3.3 \
> ${jre-${java.specification.version}}
> The process being to expand innermost variable references first and work
> outwards - this allows for very advance config, such as the above, which can
> dynamically detect the Java version and expand a JRE version specific
> property into the property being defined.
> Looking at the implementation, it seems it might be a fairly straightforward
> enhancement to:
> private int substitute(StrBuilder buf, int offset, int length, List
> priorVariables)
> The code already has the cyclic map in place.
> I already have code that achieves this within Apache Felix, so I will see if
> I can retro-fit a similar model to the above and if so submit a patch.
--
This message is automatically generated by JIRA.
-
You can reply to this email to add a comment to the issue online.
[jira] Commented: (LANG-482) Enhance StrSubstitutor to support nested ${var-${subvr}} expansion
[
https://issues.apache.org/jira/browse/LANG-482?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=12839712#action_12839712
]
Paul Benedict commented on LANG-482:
I am not a fan of substitution variables that become substitution variables. It
sounds closer to a pre-compiler. Technologies like Maven, Spring, and JSP/JSF
do not support this and, likewise, I vote not to apply this.
> Enhance StrSubstitutor to support nested ${var-${subvr}} expansion
> --
>
> Key: LANG-482
> URL: https://issues.apache.org/jira/browse/LANG-482
> Project: Commons Lang
> Issue Type: Improvement
> Components: lang.text.*
>Reporter: Rob Walker
>Priority: Minor
> Fix For: 3.1
>
> Attachments: StrSubstitutor.java.nested.patch
>
>
> t would be really handy of StrSubstitutor could support nested variable
> interpolation:
> org.osgi.framework.system.packages=org.osgi.framework; version=1.4.0, \
> org.osgi.service.packageadmin; version=1.2.0, \
> org.osgi.service.startlevel; version=1.1.0, \
> org.osgi.service.url; version=1.0.0, \
> org.osgi.util.tracker; version=1.3.3 \
> ${jre-${java.specification.version}}
> The process being to expand innermost variable references first and work
> outwards - this allows for very advance config, such as the above, which can
> dynamically detect the Java version and expand a JRE version specific
> property into the property being defined.
> Looking at the implementation, it seems it might be a fairly straightforward
> enhancement to:
> private int substitute(StrBuilder buf, int offset, int length, List
> priorVariables)
> The code already has the cyclic map in place.
> I already have code that achieves this within Apache Felix, so I will see if
> I can retro-fit a similar model to the above and if so submit a patch.
--
This message is automatically generated by JIRA.
-
You can reply to this email to add a comment to the issue online.
[jira] Created: (LANG-596) StrSubstitutor should also handle the default properties of a java.util.Properties class
StrSubstitutor should also handle the default properties of a
java.util.Properties class
Key: LANG-596
URL: https://issues.apache.org/jira/browse/LANG-596
Project: Commons Lang
Issue Type: Bug
Components: lang.text.*
Affects Versions: 2.5
Reporter: Ulrich Voigt
Priority: Minor
The following program show a problem with a shortcoming of the
java.util.Properties class.
The default properties are not substituted by the StrSubstitutor.
{code:title=StrSubstTest.java|borderStyle=solid}
import org.apache.commons.lang.text.StrSubstitutor;
public class StrSubstTest
{
public static void main(String[] args)
{
String org = "${doesnotwork}";
System.setProperty("doesnotwork", "It work's!");
// create a new Poperties object with the System.getProperties as
default
Properties props = new Properties(System.getProperties());
String subst = StrSubstitutor.replace(org, props);
// is ${doesnotwork} substituted?
System.out.println(subst);
}
}
{code}
The following method could be added to the StrSubstitutor class to fix this
problem in an easy way:
{code:borderStyle=solid}
/**
* Replaces all the occurrences of variables in the given source object
with their matching
* values from the properties.
*
* @param source the source text containing the variables to substitute,
null returns null
* @param properties the properties with values, may be null
* @return the result of the replace operation
*/
public static String replace(Object source, Properties valueProperties)
{
if (valueProperties == null) {
return source;
}
Map valueMap = new HashMap();
Enumeration propNames = valueProperties.propertyNames();
while (propNames.hasMoreElements())
{
String propName = (String)propNames.nextElement();
String propValue = valueProperties.getProperty(propName);
valueMap.put(propName, propValue);
}
return StrSubstitutor.replace(source, valueMap);
}
{code}
--
This message is automatically generated by JIRA.
-
You can reply to this email to add a comment to the issue online.
[jira] Updated: (MATH-282) ChiSquaredDistributionImpl.cumulativeProbability > 1
[ https://issues.apache.org/jira/browse/MATH-282?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Phil Steitz updated MATH-282: - Attachment: distributions.patch The attached patch resolves this issue as well as MATH-301 and the problems described above with the Poisson distribution. The patch bundles quite a few changes, some of which are not strictly necessary to resolve these issues. The following is a summary. * BrentSolver has been changed to expose its configured absolute accuracy. This solver is used by the default inverse cum implementation in AbstractContinuousDistribution and the hard-coded setting (1E-6) was limiting accuracy in inverse cumulative probability estimates. AbstractContinuousDistribution was changed to allow distributions to set this value and NormalDistributionImpl was changed to set it to 1E-9 by default and allow users to configure it via a constructor argument. If all are happy with this change, I will similarly change other distributions to override the new getSolverAbsoluteAccuracy method and add constructors to configure the value. * AbstractContinuousDistribution and AbstractIntegerDistribution inverseCumulativeProbability methods have been modified to check for NaN values returned by cumulativeProbability and throw MathExceptions when this happens. * The criteria for choosing between the Lanczos series and continued fraction expansion when computing regularized gamma functions has been changed to (x >= a + 1). When using the series approximation (regularizedGammaP), divergence to infinity is checked and when this happens, 1 is returned. * When scaling continued fractions to (try to) avoid divergence to infinity, the larger of a and b is used as a scale factor and the attempt to scale is repeated up to 5 times, using successive powers of the scale factor. * The maximum number of iterations used in estimating cumulative probabilities for PoissonDistributionImpl has been decreased from Integer.MAX_VALUE to 1000 and made configurable. Review and comment much appreciated. One thing that I would like improve is to get decent top-coding in place in terms of the arguments to the regularized gamma functions. The Poisson inverse cum tests take a very long time now because for very large values of x, the continued fractions are taking a long time to converge. This is needless computation, as the value returned is 1. We should be able to analytically determine bounds here. > ChiSquaredDistributionImpl.cumulativeProbability > 1 > > > Key: MATH-282 > URL: https://issues.apache.org/jira/browse/MATH-282 > Project: Commons Math > Issue Type: Bug >Affects Versions: 1.0, 1.1, 1.2, 2.0 > Environment: called from Scala code >Reporter: Adam Kiezun >Assignee: Phil Steitz > Fix For: 2.1 > > Attachments: distributions.patch, math-282.patch > > > Calling > new ChiSquaredDistributionImpl(1.0).cumulativeProbability(66.41528551683048) > returns 1.004, which is bogus (should never be > 1) -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online.
