[jira] [Closed] (LANG-695) SystemUtils.IS_OS_UNIX doesn't recognize FreeBSD as a Unix system
[ https://issues.apache.org/jira/browse/LANG-695?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Henri Yandell closed LANG-695. -- Resolution: Fixed Thanks. I've added these (IS_OS_FREE_BSD, IS_OS_OPEN_BSD, IS_OS_NET_BSD and then all three under IS_OS_UNIX). svn ci -m Adding FreeBSD, NetBSD and OpenBSD per Oliver's suggestion in LANG-695 Sendingsrc/main/java/org/apache/commons/lang3/SystemUtils.java Transmitting file data . Committed revision 1160564. SystemUtils.IS_OS_UNIX doesn't recognize FreeBSD as a Unix system - Key: LANG-695 URL: https://issues.apache.org/jira/browse/LANG-695 Project: Commons Lang Issue Type: Improvement Components: lang.* Affects Versions: 2.6 Environment: FreeBSD 7-STABLE Reporter: Oliver Priority: Minor Fix For: 3.0.2 FreeBSD isn't recognized as Unix system in SystemUtils.IS_OS_UNIX; There should be something like SystemUtils.IS_OS_FREEBSD, also. -- This message is automatically generated by JIRA. For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] [Created] (LANG-745) StrLookup API confusing
StrLookup API confusing --- Key: LANG-745 URL: https://issues.apache.org/jira/browse/LANG-745 Project: Commons Lang Issue Type: Bug Components: lang.* Affects Versions: 3.0 Reporter: Etienne Neveu [bayard: copying this from LANG-564] I don't see the point of having a generic type parameter on the StrLookup class, if it's not used anywhere. No method / field in StrLookup references this type parameter. IntelliJ IDEA itself reports a warning: Type parameter 'V' is never used. Moreover, Java generics are not reified, so there is no reliable way to access the type parameter at runtime (and I don't see the point of doing that anyway...). While the Javadoc tries to clarify the purpose of a StrLookup, the unused type parameter is still confusing, and the client code has to un-necessarily specify type parameters. For example, I have to write: StrLookup? lookup = StrLookup.noneLookup(); StrLookupString lookup2 = StrLookup.systemPropertiesLookup(); StrLookupInteger lookup3 = StrLookup.mapLookup(integerMap); instead of StrLookup lookup = StrLookup.noneLookup(); StrLookup lookup2 = StrLookup.systemPropertiesLookup(); StrLookup lookup3 = StrLookup.mapLookup(integerMap); My best guess is that this type parameter was added when commons-lang was generified, because StringLookup.mapLookup() takes a generified Map. Doing this is not really needed, though: we could remove the V type parameter everywhere, and replace the StrLookup.mapLookup()'s MapString, V with a MapString, ? (which is the same as MapString, ? extends Object, but shorter). I guess it's too late to change this now, due to backward compatibility... But I thought I'd comment just in case it's still possible. -- This message is automatically generated by JIRA. For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] [Commented] (LANG-564) Improve StrLookup API documentation
[ https://issues.apache.org/jira/browse/LANG-564?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=13089308#comment-13089308 ] Henri Yandell commented on LANG-564: I've put your comment in LANG-745. Closed issues are far too easy to miss comments on. Improve StrLookup API documentation --- Key: LANG-564 URL: https://issues.apache.org/jira/browse/LANG-564 Project: Commons Lang Issue Type: Bug Components: lang.text.* Reporter: Sebb Fix For: 3.0 The API for StrLookup is confused. The class has been partly genericised, but why? The Javadoc says the class is for looking up Strings which are indexed by Strings, and this agrees with the method lookup() Surely if the class is generic on V, the lookup() method should return V, not String? Does it make any sense for the class to return anything but a String? If not, then why is the class generic? If it does make sense, then lookup() should return V. -- This message is automatically generated by JIRA. For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] [Commented] (LANG-744) StringUtils throws java.security.AccessControlException on Google App Engine
[
https://issues.apache.org/jira/browse/LANG-744?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=13089311#comment-13089311
]
Henri Yandell commented on LANG-744:
No, but equally I'd like to hear when issues are found rather than hide them
before hand.
StringUtils throws java.security.AccessControlException on Google App Engine
Key: LANG-744
URL: https://issues.apache.org/jira/browse/LANG-744
Project: Commons Lang
Issue Type: Bug
Components: lang.*
Affects Versions: 3.0.1
Environment: Google App Engine
Reporter: Clément Denis
In the static initializer of org.apache.commons.lang3.StringUtils, there is
an attempt to load the class sun.text.Normalizer.
Such a class is prohibited on Google App Engine, and the static intializer
throws a java.security.AccessControlException.
{code}
Caused by: java.security.AccessControlException: access denied
(java.lang.RuntimePermission accessClassInPackage.sun.text)
at
java.security.AccessControlContext.checkPermission(AccessControlContext.java:374)
at
java.security.AccessController.checkPermission(AccessController.java:546)
at java.lang.SecurityManager.checkPermission(SecurityManager.java:532)
at
com.google.appengine.tools.development.DevAppServerFactory$CustomSecurityManager.checkPermission(DevAppServerFactory.java:166)
at
java.lang.SecurityManager.checkPackageAccess(SecurityManager.java:1512)
at java.lang.Class.checkMemberAccess(Class.java:2164)
at java.lang.Class.getMethod(Class.java:1602)
at org.apache.commons.lang3.StringUtils.clinit(StringUtils.java:739)
{code}
The exception should be caught in the catch clauses around
loadClass(sun.text.Normalizer).
Commons lang 2 worked fine on GAE.
--
This message is automatically generated by JIRA.
For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] [Resolved] (LANG-744) StringUtils throws java.security.AccessControlException on Google App Engine
[
https://issues.apache.org/jira/browse/LANG-744?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Henri Yandell resolved LANG-744.
Resolution: Fixed
Fix Version/s: 3.0.2
I've added the new exception. Feel free to reopen if you disagree Sebb.
svn ci -m Adding an exception to catch AccessControlExceptions in Google App
Engine as reported by Clément Denis in LANG-744
src/main/java/org/apache/commons/lang3/StringUtils.java
Sendingsrc/main/java/org/apache/commons/lang3/StringUtils.java
Transmitting file data .
Committed revision 1160568.
StringUtils throws java.security.AccessControlException on Google App Engine
Key: LANG-744
URL: https://issues.apache.org/jira/browse/LANG-744
Project: Commons Lang
Issue Type: Bug
Components: lang.*
Affects Versions: 3.0.1
Environment: Google App Engine
Reporter: Clément Denis
Fix For: 3.0.2
In the static initializer of org.apache.commons.lang3.StringUtils, there is
an attempt to load the class sun.text.Normalizer.
Such a class is prohibited on Google App Engine, and the static intializer
throws a java.security.AccessControlException.
{code}
Caused by: java.security.AccessControlException: access denied
(java.lang.RuntimePermission accessClassInPackage.sun.text)
at
java.security.AccessControlContext.checkPermission(AccessControlContext.java:374)
at
java.security.AccessController.checkPermission(AccessController.java:546)
at java.lang.SecurityManager.checkPermission(SecurityManager.java:532)
at
com.google.appengine.tools.development.DevAppServerFactory$CustomSecurityManager.checkPermission(DevAppServerFactory.java:166)
at
java.lang.SecurityManager.checkPackageAccess(SecurityManager.java:1512)
at java.lang.Class.checkMemberAccess(Class.java:2164)
at java.lang.Class.getMethod(Class.java:1602)
at org.apache.commons.lang3.StringUtils.clinit(StringUtils.java:739)
{code}
The exception should be caught in the catch clauses around
loadClass(sun.text.Normalizer).
Commons lang 2 worked fine on GAE.
--
This message is automatically generated by JIRA.
For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] [Commented] (LANG-693) Method createNumber from NumberUtils doesn't work for floating point numbers other than Float
[ https://issues.apache.org/jira/browse/LANG-693?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=13089318#comment-13089318 ] Henri Yandell commented on LANG-693: The toString may not be the nicest, but it definitely works :) The only test I get failing if I use it is the LANG-521 2. use case. That switches from being a Float to being a BigDecimal. I suspect there might be problems with exponents though. All the problems would seem to be creating BigDecimals unnecessarily, rather than creating Floats and losing data. So worst case the String test seems preferable. Method createNumber from NumberUtils doesn't work for floating point numbers other than Float - Key: LANG-693 URL: https://issues.apache.org/jira/browse/LANG-693 Project: Commons Lang Issue Type: Bug Components: lang.math.* Affects Versions: 2.6 Reporter: Carlos Rego Priority: Minor Fix For: 3.0.2 Method createNumber from NumberUtils is trying to parse a string with a floating point number always first as a Float, that will cause that if we send a string with a number that will need a Double or even a BigDecimal the number will be truncate to accommodate into the Float without an exception to be thrown, so in fact we will no be returning ever neither a Double nor a BigDecimal. -- This message is automatically generated by JIRA. For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] [Closed] (LANG-698) Document that the Mutable numbers don't work as expected with String.format
[ https://issues.apache.org/jira/browse/LANG-698?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Henri Yandell closed LANG-698. -- Resolution: Fixed svn ci -m Adding documentation that the Mutable numbers don't work as might be expected with String.format. LANG-698 Sendingmutable/MutableBoolean.java Sendingmutable/MutableByte.java Sendingmutable/MutableDouble.java Sendingmutable/MutableFloat.java Sendingmutable/MutableInt.java Sendingmutable/MutableLong.java Sendingmutable/MutableShort.java Transmitting file data ... Committed revision 1160571. Document that the Mutable numbers don't work as expected with String.format --- Key: LANG-698 URL: https://issues.apache.org/jira/browse/LANG-698 Project: Commons Lang Issue Type: Improvement Components: lang.mutable.* Reporter: Henri Yandell Fix For: 3.0.2 -- This message is automatically generated by JIRA. For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] [Commented] (LANG-564) Improve StrLookup API documentation
[ https://issues.apache.org/jira/browse/LANG-564?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=13089351#comment-13089351 ] Etienne Neveu commented on LANG-564: Ok. I wasn't sure whether I should create a new issue, but it makes sense since this one was closed 18 months ago. Thanks! Improve StrLookup API documentation --- Key: LANG-564 URL: https://issues.apache.org/jira/browse/LANG-564 Project: Commons Lang Issue Type: Bug Components: lang.text.* Reporter: Sebb Fix For: 3.0 The API for StrLookup is confused. The class has been partly genericised, but why? The Javadoc says the class is for looking up Strings which are indexed by Strings, and this agrees with the method lookup() Surely if the class is generic on V, the lookup() method should return V, not String? Does it make any sense for the class to return anything but a String? If not, then why is the class generic? If it does make sense, then lookup() should return V. -- This message is automatically generated by JIRA. For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] [Reopened] (LANG-744) StringUtils throws java.security.AccessControlException on Google App Engine
[
https://issues.apache.org/jira/browse/LANG-744?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Sebb reopened LANG-744:
---
Why do we care which Exceptions can be generated?
We take the same action in each case, so I don't see the point of enumerating
the Exceptions, unless there is different action to be taken for some of them.
But even then, we would probably need a catchall Exception.
StringUtils throws java.security.AccessControlException on Google App Engine
Key: LANG-744
URL: https://issues.apache.org/jira/browse/LANG-744
Project: Commons Lang
Issue Type: Bug
Components: lang.*
Affects Versions: 3.0.1
Environment: Google App Engine
Reporter: Clément Denis
Fix For: 3.0.2
In the static initializer of org.apache.commons.lang3.StringUtils, there is
an attempt to load the class sun.text.Normalizer.
Such a class is prohibited on Google App Engine, and the static intializer
throws a java.security.AccessControlException.
{code}
Caused by: java.security.AccessControlException: access denied
(java.lang.RuntimePermission accessClassInPackage.sun.text)
at
java.security.AccessControlContext.checkPermission(AccessControlContext.java:374)
at
java.security.AccessController.checkPermission(AccessController.java:546)
at java.lang.SecurityManager.checkPermission(SecurityManager.java:532)
at
com.google.appengine.tools.development.DevAppServerFactory$CustomSecurityManager.checkPermission(DevAppServerFactory.java:166)
at
java.lang.SecurityManager.checkPackageAccess(SecurityManager.java:1512)
at java.lang.Class.checkMemberAccess(Class.java:2164)
at java.lang.Class.getMethod(Class.java:1602)
at org.apache.commons.lang3.StringUtils.clinit(StringUtils.java:739)
{code}
The exception should be caught in the catch clauses around
loadClass(sun.text.Normalizer).
Commons lang 2 worked fine on GAE.
--
This message is automatically generated by JIRA.
For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] [Created] (LANG-746) NumberUtils does not handle upper-case hex: 0X and -0X
NumberUtils does not handle upper-case hex: 0X and -0X -- Key: LANG-746 URL: https://issues.apache.org/jira/browse/LANG-746 Project: Commons Lang Issue Type: Bug Reporter: Sebb NumberUtils.createNumber() should work equally for 0x1234 and 0X1234; currently 0X1234 generates a NumberFormatException Integer.decode() handles both upper and lower case hex. -- This message is automatically generated by JIRA. For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] [Updated] (LANG-746) NumberUtils does not handle upper-case hex: 0X and -0X
[ https://issues.apache.org/jira/browse/LANG-746?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Sebb updated LANG-746: -- Affects Version/s: 3.0 3.0.1 Fix Version/s: 3.0.2 NumberUtils does not handle upper-case hex: 0X and -0X -- Key: LANG-746 URL: https://issues.apache.org/jira/browse/LANG-746 Project: Commons Lang Issue Type: Bug Affects Versions: 3.0, 3.0.1 Reporter: Sebb Fix For: 3.0.2 NumberUtils.createNumber() should work equally for 0x1234 and 0X1234; currently 0X1234 generates a NumberFormatException Integer.decode() handles both upper and lower case hex. -- This message is automatically generated by JIRA. For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] [Resolved] (LANG-746) NumberUtils does not handle upper-case hex: 0X and -0X
[ https://issues.apache.org/jira/browse/LANG-746?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Sebb resolved LANG-746. --- Resolution: Fixed URL: http://svn.apache.org/viewvc?rev=1160660view=rev Log: LANG-746 NumberUtils does not handle upper-case hex: 0X and -0X Modified: commons/proper/lang/trunk/src/main/java/org/apache/commons/lang3/math/NumberUtils.java commons/proper/lang/trunk/src/site/changes/changes.xml commons/proper/lang/trunk/src/test/java/org/apache/commons/lang3/math/NumberUtilsTest.java NumberUtils does not handle upper-case hex: 0X and -0X -- Key: LANG-746 URL: https://issues.apache.org/jira/browse/LANG-746 Project: Commons Lang Issue Type: Bug Affects Versions: 3.0, 3.0.1 Reporter: Sebb NumberUtils.createNumber() should work equally for 0x1234 and 0X1234; currently 0X1234 generates a NumberFormatException Integer.decode() handles both upper and lower case hex. -- This message is automatically generated by JIRA. For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] [Commented] (CHAIN-53) Global Update of Chain - Generics, JDK 1.5, Update Dependency Versions
[
https://issues.apache.org/jira/browse/CHAIN-53?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=13089427#comment-13089427
]
Simone Tripodi commented on CHAIN-53:
-
Elijah,
as discussed in the [ML|http://markmail.org/message/lnusnwl6gd6eb3p2], I
created a
[branch|https://svn.apache.org/repos/asf/commons/proper/chain/branches/version-2.0-work]
where I'm trying to apply the patch, unfortunately I didn't have success; what
I executed is
{code}
patch -p0 v2_patch_2011-08-18.diff
{code}
and got the following error list
{code}
patching file
src/test/java/org/apache/commons/chain/impl/NonDelegatingCommand.java
Hunk #1 succeeded at 29 with fuzz 1.
patching file
src/test/java/org/apache/commons/chain/generic/DispatchLookupCommandTestCase.java
patching file
src/test/java/org/apache/commons/chain/generic/LookupCommandTestCase.java
patching file
src/test/java/org/apache/commons/chain/generic/DispatchCommandTestCase.java
patching file
src/test/java/org/apache/commons/chain/web/servlet/MockServletContext.java
patching file
src/test/java/org/apache/commons/chain/web/servlet/ServletWebContextTestCase.java
patching file
src/test/java/org/apache/commons/chain/web/portlet/MockPortletSession.java
patching file
src/test/java/org/apache/commons/chain/web/portlet/MockPortletContext.java
patching file
src/test/java/org/apache/commons/chain/web/portlet/MockPortletRequest.java
patching file src/main/java/org/apache/commons/chain/impl/ContextBase.java
Hunk #2 succeeded at 52 with fuzz 1.
patching file src/main/java/org/apache/commons/chain/impl/CatalogBase.java
patching file
src/main/java/org/apache/commons/chain/impl/CatalogFactoryBase.java
patching file src/main/java/org/apache/commons/chain/impl/ChainBase.java
Hunk #1 FAILED at 28.
1 out of 8 hunks FAILED -- saving rejects to file
src/main/java/org/apache/commons/chain/impl/ChainBase.java.rej
patching file src/main/java/org/apache/commons/chain/CatalogFactory.java
patching file src/main/java/org/apache/commons/chain/Chain.java
Hunk #1 FAILED at 47.
1 out of 3 hunks FAILED -- saving rejects to file
src/main/java/org/apache/commons/chain/Chain.java.rej
patching file src/main/java/org/apache/commons/chain/Context.java
Hunk #1 succeeded at 60 with fuzz 1.
patching file
src/main/java/org/apache/commons/chain/config/ConfigRegisterRule.java
patching file
src/main/java/org/apache/commons/chain/config/ConfigCatalogRule.java
patching file
src/main/java/org/apache/commons/chain/config/ConfigDefineRule.java
patching file src/main/java/org/apache/commons/chain/Filter.java
Hunk #1 FAILED at 37.
1 out of 2 hunks FAILED -- saving rejects to file
src/main/java/org/apache/commons/chain/Filter.java.rej
patching file src/main/java/org/apache/commons/chain/Catalog.java
patching file
src/main/java/org/apache/commons/chain/generic/DispatchLookupCommand.java
Hunk #1 FAILED at 47.
1 out of 7 hunks FAILED -- saving rejects to file
src/main/java/org/apache/commons/chain/generic/DispatchLookupCommand.java.rej
patching file src/main/java/org/apache/commons/chain/generic/LookupCommand.java
Hunk #1 FAILED at 40.
1 out of 6 hunks FAILED -- saving rejects to file
src/main/java/org/apache/commons/chain/generic/LookupCommand.java.rej
patching file src/main/java/org/apache/commons/chain/generic/CopyCommand.java
Hunk #1 FAILED at 25.
1 out of 2 hunks FAILED -- saving rejects to file
src/main/java/org/apache/commons/chain/generic/CopyCommand.java.rej
patching file src/main/java/org/apache/commons/chain/generic/RemoveCommand.java
Hunk #1 FAILED at 24.
1 out of 2 hunks FAILED -- saving rejects to file
src/main/java/org/apache/commons/chain/generic/RemoveCommand.java.rej
patching file
src/main/java/org/apache/commons/chain/generic/DispatchCommand.java
patching file src/main/java/org/apache/commons/chain/web/MapEntry.java
Hunk #1 FAILED at 24.
1 out of 7 hunks FAILED -- saving rejects to file
src/main/java/org/apache/commons/chain/web/MapEntry.java.rej
patching file
src/main/java/org/apache/commons/chain/web/faces/FacesGetLocaleCommand.java
patching file
src/main/java/org/apache/commons/chain/web/faces/FacesWebContext.java
patching file
src/main/java/org/apache/commons/chain/web/faces/FacesSetLocaleCommand.java
patching file
src/main/java/org/apache/commons/chain/web/AbstractGetLocaleCommand.java
Hunk #1 FAILED at 27.
1 out of 3 hunks FAILED -- saving rejects to file
src/main/java/org/apache/commons/chain/web/AbstractGetLocaleCommand.java.rej
patching file src/main/java/org/apache/commons/chain/web/WebContext.java
patching file
src/main/java/org/apache/commons/chain/web/servlet/ServletApplicationScopeMap.java
Hunk #2 succeeded at 36 with fuzz 1.
patching file
src/main/java/org/apache/commons/chain/web/servlet/ServletGetLocaleCommand.java
patching file
src/main/java/org/apache/commons/chain/web/servlet/ServletParamMap.java
Hunk #2 succeeded at 36 with fuzz 1.
patching file
[jira] [Created] (LANG-747) NumberUtils does not handle Long Hex numbers
NumberUtils does not handle Long Hex numbers Key: LANG-747 URL: https://issues.apache.org/jira/browse/LANG-747 Project: Commons Lang Issue Type: Bug Reporter: Sebb NumberUtils.createLong() does not handle hex numbers, but createInteger() handles hex and octal. This seems odd. NumberUtils.createNumber() assumes that hex numbers can only be Integer. Again, why not handle bigger Hex numbers? == It is trivial to fix createLong() - just use Long.decode() instead of valueOf(). It's not clear why this was not done originally - the decode() method was added to both Integer and Long in Java 1.2. Fixing createNumber() is also fairly easy - if the hex string has more than 8 digits, use Long. Should we allow for leading zeros in an Integer? If not, the length check is trivial. -- This message is automatically generated by JIRA. For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] [Resolved] (MATH-464) LegendreGaussIntegrator ignores defaultMaximalIterationCount and does 38 million iterations
[
https://issues.apache.org/jira/browse/MATH-464?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Luc Maisonobe resolved MATH-464.
Resolution: Fixed
Fixed in subversion repository as of r1160914.
The API of the integrators has been changed for consistency with solvers API.
Now the main convergence parameters are set in the constructor and remain
fixed, but a maximal number of function evaluation must be provided at each
call to the integration method.
Thanks for the report
LegendreGaussIntegrator ignores defaultMaximalIterationCount and does 38
million iterations
---
Key: MATH-464
URL: https://issues.apache.org/jira/browse/MATH-464
Project: Commons Math
Issue Type: Bug
Affects Versions: 2.1
Reporter: Michael Borcherds
Priority: Critical
Fix For: 3.0
Original Estimate: 3h
Remaining Estimate: 3h
The following code results in count = 37801710 which is effectively an
infinite loop for typical functions we are using
(in GeoGebra)
The argument defaultMaximalIterationCount = 100 is being ignored
This is the version we are using:
http://www.geogebra.org/trac/browser/trunk/geogebra/org/apache/commons/math/analysis/integration/LegendreGaussIntegrator.java
LegendreGaussIntegrator gauss = new LegendreGaussIntegrator(5, 100);
try {
double result = gauss.integrate(new testFun(), -10,
0.32462367623786328);
} catch (Exception ee) {
ee.printStackTrace();
}
class testFun implements UnivariateRealFunction {
public double value(double x) throws FunctionEvaluationException {
count ++;
if (x=0 x=5) return 0.2; else return 0;
}
}
--
This message is automatically generated by JIRA.
For more information on JIRA, see: http://www.atlassian.com/software/jira
