[jira] Created: (VFS-169) Thrown exception reveals passwords
Thrown exception reveals passwords -- Key: VFS-169 URL: https://issues.apache.org/jira/browse/VFS-169 Project: Commons VFS Issue Type: Bug Affects Versions: 1.0 Reporter: Joerg Schaible If an exception occurs accessing a FileObject on a FileSystem that is addressed with an URL containing user and password the thrown exception contains the password as part of the error message: org.apache.commons.vfs.FileSystemException: Could not connect to SFTP server at sftp://user:[EMAIL PROTECTED]/. In such a case the URL should be printed as sftp://user:[EMAIL PROTECTED]/. Same applied to log messages - at least for INFO and higher. This is a security risk, since in big companies exceptions and logs are normally collected and archived in monitoring systems and may reveal the password to persons that have normally no authorization to the target system. -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online. - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
[jira] Commented: (LOGGING-114) Silent Swallowing of NoClassDefFoundError
[ https://issues.apache.org/jira/browse/LOGGING-114?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel#action_12511709 ] Joerg Schaible commented on LOGGING-114: IMHO this is really a JCL problem. It detects log4j and tries to use it. It is fine that it searches for something else if log4j is not present. But here it even suppresses a thrown Error that indicates also a problem for JCL. From user's PoV either the presence of log4j was not expected at all, he failed to configure to Log4J or he failed to configure JCL. In any case he must realize that something is not working as expected. Silent Swallowing of NoClassDefFoundError - Key: LOGGING-114 URL: https://issues.apache.org/jira/browse/LOGGING-114 Project: Commons Logging Issue Type: Bug Affects Versions: 1.1.0 Environment: Various OSs, in combination with log4j 1.2.14. Reporter: Malcolm Cleaton Priority: Minor Hi. I'm using commons logging with log4j; my team ship a library which uses log4j, and some of our clients use it with commons-logging. If commons-logging is in its default configuration, and log4j is present but fails to load its configuration with an unhandled exception, the results are pretty nasty: - commons-logging silently swallows the exception and logs with something else. If diagnostics are turned on, the message is: Could not instantiate Log 'org.apache.commons.logging.impl.Log4JLogger' -- java.lang.reflect.InvocationTargetException: null - future attempts to use log4j directly get a pretty unhelpful error: java.lang.NoClassDefFoundError at org.apache.log4j.Logger.getLogger(Logger.java:117). I realise you're trying to deal with a very large number of cases in this code, but it does seem like something better could be done here. If nothing else is possible, at least recognising the InvocationTargetException and pulling out the target exception for the diagnostic log would have helped with tracking this one down. -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online. - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
[jira] Commented: (CONFIGURATION-284) ability to read OS environment variables
[
https://issues.apache.org/jira/browse/CONFIGURATION-284?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel#action_12510608
]
Joerg Schaible commented on CONFIGURATION-284:
--
Interpolation for system properties is already available, simply set up your
configuration properly:
{code:java}
final CompositeConfiguration configuration = new
CompositeConfiguration();
// system properties override every setting
configuration.addConfiguration(ConfigurationConverter.getConfiguration(System.getProperties()));
// add other configuration instances here
{code}
ability to read OS environment variables
Key: CONFIGURATION-284
URL: https://issues.apache.org/jira/browse/CONFIGURATION-284
Project: Commons Configuration
Issue Type: New Feature
Components: Interpolation
Reporter: Aksel Schmidt
Priority: Minor
suggestion:
interpolation with system environment, i.e.
${sys:user.name} reads from systemproperties (as of today)
${sysenv:TEMP} reads from OS environment
these can be parsed from a supported set of OS's - windows read from a set in
a cmd /c, unix/linux from an env etc. (just once on demand)
--
This message is automatically generated by JIRA.
-
You can reply to this email to add a comment to the issue online.
-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
[jira] Issue Comment Edited: (CONFIGURATION-284) ability to read OS environment variables
[
https://issues.apache.org/jira/browse/CONFIGURATION-284?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel#action_12510608
]
Joerg Schaible edited comment on CONFIGURATION-284 at 7/6/07 12:08 AM:
---
Interpolation for system properties is already available, simply set up your
configuration properly:
{noformat}
final CompositeConfiguration configuration = new CompositeConfiguration();
// system properties override every setting
configuration.addConfiguration(ConfigurationConverter.getConfiguration(System.getProperties()));
// add other configuration instances here
{noformat}
was:
Interpolation for system properties is already available, simply set up your
configuration properly:
{code:java}
final CompositeConfiguration configuration = new
CompositeConfiguration();
// system properties override every setting
configuration.addConfiguration(ConfigurationConverter.getConfiguration(System.getProperties()));
// add other configuration instances here
{code}
ability to read OS environment variables
Key: CONFIGURATION-284
URL: https://issues.apache.org/jira/browse/CONFIGURATION-284
Project: Commons Configuration
Issue Type: New Feature
Components: Interpolation
Reporter: Aksel Schmidt
Priority: Minor
suggestion:
interpolation with system environment, i.e.
${sys:user.name} reads from systemproperties (as of today)
${sysenv:TEMP} reads from OS environment
these can be parsed from a supported set of OS's - windows read from a set in
a cmd /c, unix/linux from an env etc. (just once on demand)
--
This message is automatically generated by JIRA.
-
You can reply to this email to add a comment to the issue online.
-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
[jira] Commented: (VFS-139) Fix javac 1.5 warnings
[ https://issues.apache.org/jira/browse/VFS-139?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel#action_12495596 ] Joerg Schaible commented on VFS-139: Cast the null value. Fix javac 1.5 warnings -- Key: VFS-139 URL: https://issues.apache.org/jira/browse/VFS-139 Project: Commons VFS Issue Type: Improvement Affects Versions: 1.1 Reporter: Adam Heath Priority: Trivial Fix For: 1.1 Attachments: fix_java15-warnings.patch In java1.5, javac has support for varargs. It does this by auto-creating an array of the appropriate type, when a variable number of parameters are passed. However, in such cases, when a null is passed to such a method, it isn't completely sure how to proceed. Should it create an array with a single null value, or should it just pass the null value straight thru? In any event, the attached patch fixes it. -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online. - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
[jira] Commented: (CONFIGURATION-203) [configuration] Make Configuration Serializable
[ https://issues.apache.org/jira/browse/CONFIGURATION-203?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel#action_12478222 ] Joerg Schaible commented on CONFIGURATION-203: -- You may consider implementing the writeReplace method. This allows you to serialize every Configuration into a tailored version especially designed for serialization. You may even have different impls e.g. a different one for hierarchical configs. However, some features like reloading do not make really sense for some sources ... what is a file URL really worth after serialization? [configuration] Make Configuration Serializable --- Key: CONFIGURATION-203 URL: https://issues.apache.org/jira/browse/CONFIGURATION-203 Project: Commons Configuration Issue Type: Improvement Affects Versions: 1.1 Environment: Operating System: other Platform: Other Reporter: Joe Wolf Priority: Minor Fix For: 1.5 It would be nice if org.apache.commons.configuration.Configuration extended java.io.Serializable and its implementations were serializable as well. Theoretically, most configurations are constructed from serialized data sources. -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online. - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
[jira] Created: (IO-115) FileUtilsCleanDirectoryTestCase fails on Windoes if command chmod is available
FileUtilsCleanDirectoryTestCase fails on Windoes if command chmod is available -- Key: IO-115 URL: https://issues.apache.org/jira/browse/IO-115 Project: Commons IO Issue Type: Bug Components: Utilities Affects Versions: 1.3.1 Reporter: Joerg Schaible Fix For: 1.3.1 Some tests in FileUtilsCleanDirectoryTestCase try to delete files that have been set to read-only. This is expected to throw an exception. To set the read-only flag the method chmod() tries to execute the unix chmod command. If this fails (which should normally be the case on windows), the test is ignored. If Posix tools are available e.g. from Cygwin, MKS Toolkit, Microsoft's Posix Tools or similar ones the test fails. -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online. - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
[jira] Commented: (LANG-317) Enum Serialization - not backwards compatible
[ https://issues.apache.org/jira/browse/LANG-317?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel#action_1247 ] Joerg Schaible commented on LANG-317: - This has less to do with the JDK, but more with the compiler you're using. E.g. if you have compiled the class with Eclipse (it uses *always* the internal compiler and not the selected JDK's one) it will have a different serialVersionUID generated that the same class from the Sun compiler from the identical JDK. The only way to get them compatible is to define an own serialVersionUID. Enum Serialization - not backwards compatible - Key: LANG-317 URL: https://issues.apache.org/jira/browse/LANG-317 Project: Commons Lang Issue Type: Bug Affects Versions: 2.2 Environment: JDK 1.5 - JDK 1.4 Reporter: U. Klinkmüller Priority: Critical In our distributed application we have to deal with different environments. The server runs in a JDK 1.5 environment while some clients runs with JDK 1.4. In this scenario we get an error when we try to transfer the result object via RMI. The error message is: Exception:BusinessDelegatorComp.login() - connection error ocurred during loginCORBA MARSHAL 0x4942f89a No; nested exception is: org.omg.CORBA.MARSHAL: Unable to read value from underlying bridge : Mismatched serialization UIDs : Source (Rep. IDRMI:de.fraport.biaf.apm.user.UserRoleEnum:CBEF51ADA936FFFE:D100D6F29BD50386) = D100D6F29BD50386 whereas Target (Rep. ID RMI:de.fraport.biaf.apm.user.UserRoleEnum:CBEF51ADA936FFFE:D041682DA5693C42) = D041682DA5693C42 vmcid: IBM minor code: 89A completed: No The class causing this problem is derived from org.apache.commons.lang.enums.ValuedEnum. Aftre some recherches we found on http://people.apache.org/~bayard/ that there is a upcoming new release 2.3 of Commons-Lang. We saw that in this release a bug [LANG-286] has been fixed which seemed to be exactly our problem. We downloaded this version hopening that we can forget this problem. But unfortunately the problem still exists. -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online. - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
[jira] Created: (COMMONSSITE-14) ApacheCon advertisement does not work for Konqueror
ApacheCon advertisement does not work for Konqueror
---
Key: COMMONSSITE-14
URL: https://issues.apache.org/jira/browse/COMMONSSITE-14
Project: Commons All
Issue Type: Bug
Components: Site
Environment: Gentoo Linux, Konqueror 3.5.5
Reporter: Joerg Schaible
Priority: Minor
The ad for the ApacheCon is injected into the site by a style for the
leftColumn:
{code:css}
div#leftColumn {
color: #000;
background-color: #eee;
margin-left: 0px;
margin-top: 0px;
border-right: 1px solid #aaa;
border-bottom: 1px solid #aaa;
border-top: none;
border-left: none;
width: 150px;
background-image:url(http://www.apache.org/ads/ApacheCon/2007-europe-125x125.png);
background-repeat: no-repeat;
background-position: 50% 1%;
}
{code}
The image does not show up with Konqueror though, the space stays just empty
!navi.gif!
This does not
--
This message is automatically generated by JIRA.
-
You can reply to this email to add a comment to the issue online.
-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
[jira] Updated: (COMMONSSITE-14) ApacheCon advertisement does not work for Konqueror
[
https://issues.apache.org/jira/browse/COMMONSSITE-14?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Joerg Schaible updated COMMONSSITE-14:
--
Attachment: navi.gif
ApacheCon advertisement does not work for Konqueror
---
Key: COMMONSSITE-14
URL: https://issues.apache.org/jira/browse/COMMONSSITE-14
Project: Commons All
Issue Type: Bug
Components: Site
Environment: Gentoo Linux, Konqueror 3.5.5
Reporter: Joerg Schaible
Priority: Minor
Attachments: navi.gif
The ad for the ApacheCon is injected into the site by a style for the
leftColumn:
{code:css}
div#leftColumn {
color: #000;
background-color: #eee;
margin-left: 0px;
margin-top: 0px;
border-right: 1px solid #aaa;
border-bottom: 1px solid #aaa;
border-top: none;
border-left: none;
width: 150px;
background-image:url(http://www.apache.org/ads/ApacheCon/2007-europe-125x125.png);
background-repeat: no-repeat;
background-position: 50% 1%;
}
{code}
The image does not show up with Konqueror though, the space stays just empty
!navi.gif!
This does not
--
This message is automatically generated by JIRA.
-
You can reply to this email to add a comment to the issue online.
-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
[jira] Created: (LANG-318) HashCodeBuilderTest and ToStringBuilderTest fail with IBM JDK 1.4.2
HashCodeBuilderTest and ToStringBuilderTest fail with IBM JDK 1.4.2
---
Key: LANG-318
URL: https://issues.apache.org/jira/browse/LANG-318
Project: Commons Lang
Issue Type: Bug
Affects Versions: 2.2
Environment: Gentoo Linux, IBM JDK 1.4.2_5
Reporter: Joerg Schaible
Priority: Minor
The IBM JDK 1.4.2 reports the declared fields of a class in reverse declaration
order. The tests are affected by this:
{noformat}
Testsuite: org.apache.commons.lang.builder.BuilderTestSuite
Tests run: 263, Failures: 8, Errors: 0, Time elapsed: 0,451 sec
Testcase:
testReflectionHierarchyHashCode(org.apache.commons.lang.builder.HashCodeBuilderTest):
FAILED
expected:11785967 but was:1276487
junit.framework.AssertionFailedError: expected:11785967 but was:1276487
at
org.apache.commons.lang.builder.HashCodeBuilderTest.testReflectionHierarchyHashCode(HashCodeBuilderTest.java:166)
at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method)
at
sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:85)
at
sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:58)
at
sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:60)
Testcase:
testReflectionHashCodeExcludeFields(org.apache.commons.lang.builder.HashCodeBuilderTest):
FAILED
expected:862547 but was:865283
junit.framework.AssertionFailedError: expected:862547 but was:865283
at
org.apache.commons.lang.builder.HashCodeBuilderTest.testReflectionHashCodeExcludeFields(HashCodeBuilderTest.java:480)
at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method)
at
sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:85)
at
sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:58)
at
sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:60)
Testcase:
testReflectionHierarchyArrayList(org.apache.commons.lang.builder.ToStringBuilderTest):
FAILED
expected:...elementData={null,null,null,null,null,null,null,null,null,null},size=0...
but
was:...size=0,elementData={null,null,null,null,null,null,null,null,null,null}...
junit.framework.ComparisonFailure:
expected:...elementData={null,null,null,null,null,null,null,null,null,null},size=0...
but
was:...size=0,elementData={null,null,null,null,null,null,null,null,null,null}...
at
org.apache.commons.lang.builder.ToStringBuilderTest.testReflectionHierarchyArrayList(ToStringBuilderTest.java:327)
at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method)
at
sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:85)
at
sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:58)
at
sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:60)
Testcase:
testReflectionHierarchy(org.apache.commons.lang.builder.ToStringBuilderTest):
FAILED
expected:...a=a,transientA=t... but was:...transientA=t,a=a...
junit.framework.ComparisonFailure: expected:...a=a,transientA=t... but
was:...transientA=t,a=a...
at
org.apache.commons.lang.builder.ToStringBuilderTest.testReflectionHierarchy(ToStringBuilderTest.java:338)
at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method)
at
sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:85)
at
sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:58)
at
sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:60)
Testcase:
testSelfInstanceTwoVarsReflectionObjectCycle(org.apache.commons.lang.builder.ToStringBuilderTest):
FAILED
expected:[EMAIL PROTECTED],otherType=The
Other Type... but was:...otherType=The Other
Type,[EMAIL PROTECTED]
junit.framework.ComparisonFailure:
expected:[EMAIL PROTECTED],otherType=The
Other Type... but was:...otherType=The Other
Type,[EMAIL PROTECTED]
at
org.apache.commons.lang.builder.ToStringBuilderTest.testSelfInstanceTwoVarsReflectionObjectCycle(ToStringBuilderTest.java:543)
at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method)
at
sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:85)
at
sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:58)
at
sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:60)
Testcase:
testSimpleReflectionStatics(org.apache.commons.lang.builder.ToStringBuilderTest):
FAILED
expected:...String=staticString,staticInt=12345... but
was:...Int=12345,staticString=staticString...
junit.framework.ComparisonFailure:
expected:...String=staticString,staticInt=12345... but
was:...Int=12345,staticString=staticString...
at
[jira] Created: (LANG-319) CharEncodingTest fails in IBM JDK 1.4.2
CharEncodingTest fails in IBM JDK 1.4.2 --- Key: LANG-319 URL: https://issues.apache.org/jira/browse/LANG-319 Project: Commons Lang Issue Type: Bug Affects Versions: 2.2 Environment: Gentoo Linux, IBM JDK 1.4.2_5 Reporter: Joerg Schaible Priority: Minor The test CharEncodingTest.testNotSupported tests with invalid character encodings. According the JDK docu of String(byte[], String) the JDK should throw in this case an java.lang.UnsupportedCharacterEncoding exception, but the IBM JDK 1.4.2 throws java.nio.charset.IllegalCharsetNameException. This is not an issue with IBM JDK 1.5.0_3 anymore. -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online. - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
[jira] Closed: (LANG-319) CharEncodingTest fails in IBM JDK 1.4.2
[ https://issues.apache.org/jira/browse/LANG-319?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Joerg Schaible closed LANG-319. --- Resolution: Won't Fix Fix Version/s: 2.3 This is a JDK bug and we cannot catch the thrown exception, since it is only available in JDK 1.4+. CharEncodingTest fails in IBM JDK 1.4.2 --- Key: LANG-319 URL: https://issues.apache.org/jira/browse/LANG-319 Project: Commons Lang Issue Type: Bug Affects Versions: 2.2 Environment: Gentoo Linux, IBM JDK 1.4.2_5 Reporter: Joerg Schaible Assigned To: Joerg Schaible Priority: Minor Fix For: 2.3 The test CharEncodingTest.testNotSupported tests with invalid character encodings. According the JDK docu of String(byte[], String) the JDK should throw in this case an java.lang.UnsupportedCharacterEncoding exception, but the IBM JDK 1.4.2 throws java.nio.charset.IllegalCharsetNameException. This is not an issue with IBM JDK 1.5.0_3 anymore. -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online. - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
[jira] Commented: (LANG-318) HashCodeBuilderTest and ToStringBuilderTest fail with IBM JDK 1.4.2
[
https://issues.apache.org/jira/browse/LANG-318?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel#action_12471821
]
Joerg Schaible commented on LANG-318:
-
This is not an issue with IBM JDK 1.5.0_3 anymore.
HashCodeBuilderTest and ToStringBuilderTest fail with IBM JDK 1.4.2
---
Key: LANG-318
URL: https://issues.apache.org/jira/browse/LANG-318
Project: Commons Lang
Issue Type: Bug
Affects Versions: 2.2
Environment: Gentoo Linux, IBM JDK 1.4.2_5
Reporter: Joerg Schaible
Priority: Minor
The IBM JDK 1.4.2 reports the declared fields of a class in reverse
declaration order. The tests are affected by this:
{noformat}
Testsuite: org.apache.commons.lang.builder.BuilderTestSuite
Tests run: 263, Failures: 8, Errors: 0, Time elapsed: 0,451 sec
Testcase:
testReflectionHierarchyHashCode(org.apache.commons.lang.builder.HashCodeBuilderTest):
FAILED
expected:11785967 but was:1276487
junit.framework.AssertionFailedError: expected:11785967 but was:1276487
at
org.apache.commons.lang.builder.HashCodeBuilderTest.testReflectionHierarchyHashCode(HashCodeBuilderTest.java:166)
at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method)
at
sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:85)
at
sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:58)
at
sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:60)
Testcase:
testReflectionHashCodeExcludeFields(org.apache.commons.lang.builder.HashCodeBuilderTest):
FAILED
expected:862547 but was:865283
junit.framework.AssertionFailedError: expected:862547 but was:865283
at
org.apache.commons.lang.builder.HashCodeBuilderTest.testReflectionHashCodeExcludeFields(HashCodeBuilderTest.java:480)
at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method)
at
sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:85)
at
sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:58)
at
sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:60)
Testcase:
testReflectionHierarchyArrayList(org.apache.commons.lang.builder.ToStringBuilderTest):
FAILED
expected:...elementData={null,null,null,null,null,null,null,null,null,null},size=0...
but
was:...size=0,elementData={null,null,null,null,null,null,null,null,null,null}...
junit.framework.ComparisonFailure:
expected:...elementData={null,null,null,null,null,null,null,null,null,null},size=0...
but
was:...size=0,elementData={null,null,null,null,null,null,null,null,null,null}...
at
org.apache.commons.lang.builder.ToStringBuilderTest.testReflectionHierarchyArrayList(ToStringBuilderTest.java:327)
at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method)
at
sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:85)
at
sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:58)
at
sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:60)
Testcase:
testReflectionHierarchy(org.apache.commons.lang.builder.ToStringBuilderTest):
FAILED
expected:...a=a,transientA=t... but was:...transientA=t,a=a...
junit.framework.ComparisonFailure: expected:...a=a,transientA=t... but
was:...transientA=t,a=a...
at
org.apache.commons.lang.builder.ToStringBuilderTest.testReflectionHierarchy(ToStringBuilderTest.java:338)
at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method)
at
sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:85)
at
sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:58)
at
sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:60)
Testcase:
testSelfInstanceTwoVarsReflectionObjectCycle(org.apache.commons.lang.builder.ToStringBuilderTest):
FAILED
expected:[EMAIL PROTECTED],otherType=The
Other Type... but was:...otherType=The Other
Type,[EMAIL PROTECTED]
junit.framework.ComparisonFailure:
expected:[EMAIL PROTECTED],otherType=The
Other Type... but was:...otherType=The Other
Type,[EMAIL PROTECTED]
at
org.apache.commons.lang.builder.ToStringBuilderTest.testSelfInstanceTwoVarsReflectionObjectCycle(ToStringBuilderTest.java:543)
at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method)
at
sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:85)
at
sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:58)
at
sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:60)
Testcase:
[jira] Created: (LANG-320) LocaleUtilsTest fails with IBM JDK 1.5.0 because of false assuptions
LocaleUtilsTest fails with IBM JDK 1.5.0 because of false assuptions Key: LANG-320 URL: https://issues.apache.org/jira/browse/LANG-320 Project: Commons Lang Issue Type: Bug Affects Versions: 2.2 Reporter: Joerg Schaible LocaleUtilsTest.testLanguagesByCountry makes the assumption, that within the JDK there is only one language defined for GB: en. This is not true for the IBM JDK 1.5.0 that also knows about cy_GB i.e. Welsh. -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online. - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
[jira] Commented: (LANG-320) LocaleUtilsTest fails with IBM JDK 1.5.0 because of false assuptions
[ https://issues.apache.org/jira/browse/LANG-320?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel#action_12471849 ] Joerg Schaible commented on LANG-320: - This test in special has not to do much with the vendor. Sun might deliver the cy_GB local with every new patch and then the test will fails also. LANG-318 is different though. LocaleUtilsTest fails with IBM JDK 1.5.0 because of false assuptions Key: LANG-320 URL: https://issues.apache.org/jira/browse/LANG-320 Project: Commons Lang Issue Type: Bug Affects Versions: 2.2 Reporter: Joerg Schaible LocaleUtilsTest.testLanguagesByCountry makes the assumption, that within the JDK there is only one language defined for GB: en. This is not true for the IBM JDK 1.5.0 that also knows about cy_GB i.e. Welsh. -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online. - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
[jira] Commented: (DISCOVERY-10) Add jar target to commons-discovery build.xml
[ https://issues.apache.org/jira/browse/DISCOVERY-10?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel#action_12466408 ] Joerg Schaible commented on DISCOVERY-10: - Hi Petteri, commons-discovery (as all other Jakarta commons components) will use now Maven 2 to build the package. That means any available build.xml will be generated by Maven and not edited manually. - Jörg Add jar target to commons-discovery build.xml - Key: DISCOVERY-10 URL: https://issues.apache.org/jira/browse/DISCOVERY-10 Project: Commons Discovery Issue Type: Bug Affects Versions: 0.4 Reporter: Petteri Räty Priority: Minor Fix For: Nightly Builds Attachments: commons-discovery-jar-target.patch I added the jar target so that you don't have to generate javadocs to be able to build the jar file. This is required to follow the Gentoo java packaging policy and is the most common build.xml target layout. -- This message is automatically generated by JIRA. - If you think it was sent incorrectly contact one of the administrators: https://issues.apache.org/jira/secure/Administrators.jspa - For more information on JIRA, see: http://www.atlassian.com/software/jira - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
[jira] Commented: (IO-94) New Mock InputStream Writer implementations
[ http://issues.apache.org/jira/browse/IO-94?page=comments#action_12441670 ] Joerg Schaible commented on IO-94: -- Personally I have always used (CGLIB-enhanced) jMock to create mocks of streams on the fly. Therefore I agree with Stephen, that this is not really something that should be included into the runtime part. Moving to test is IMHO fine though. New Mock InputStream Writer implementations - Key: IO-94 URL: http://issues.apache.org/jira/browse/IO-94 Project: Commons IO Issue Type: New Feature Components: Streams/Writers Reporter: Niall Pemberton Assigned To: Niall Pemberton Priority: Minor Fix For: 1.3 Attachments: MockInputStream.java, MockInputStreamTestCase.java I have created a MockInputStream which can be plugged in for testing parts of systems where the data doesn't matter - the main use I've had for it was testing large files - without actually having the InputStream process large amounts of bytes. -- This message is automatically generated by JIRA. - If you think it was sent incorrectly contact one of the administrators: http://issues.apache.org/jira/secure/Administrators.jspa - For more information on JIRA, see: http://www.atlassian.com/software/jira - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
[jira] Commented: (IO-94) New Mock InputStream Writer implementations
[ http://issues.apache.org/jira/browse/IO-94?page=comments#action_12441674 ] Joerg Schaible commented on IO-94: -- Yes, but not *that* easy :) But what I really needed and wrote once was a NullInputStream of a specific capacity delivering bytes of value 0 (because of assembling a data stream on the fly for a format with 'holes'). Maybe such an implementation with an arbitrary byte value might be added as ConstantInputStream with a certain capacity. Something like this should be similar/equal to the MockInputStream but does not sound so determined for test ;-) New Mock InputStream Writer implementations - Key: IO-94 URL: http://issues.apache.org/jira/browse/IO-94 Project: Commons IO Issue Type: New Feature Components: Streams/Writers Reporter: Niall Pemberton Assigned To: Niall Pemberton Priority: Minor Fix For: 1.3 Attachments: MockInputStream.java, MockInputStreamTestCase.java I have created a MockInputStream which can be plugged in for testing parts of systems where the data doesn't matter - the main use I've had for it was testing large files - without actually having the InputStream process large amounts of bytes. -- This message is automatically generated by JIRA. - If you think it was sent incorrectly contact one of the administrators: http://issues.apache.org/jira/secure/Administrators.jspa - For more information on JIRA, see: http://www.atlassian.com/software/jira - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
[jira] Reopened: (CONFIGURATION-216) Inconsistent way to locate filename when creating configuration
[ http://issues.apache.org/jira/browse/CONFIGURATION-216?page=all ] Joerg Schaible reopened CONFIGURATION-216: -- Reopened by request. Since the bug is only resolved, you should have been able to do so yourself. But maybe there's a flaw in the JIRA workflow configuration ... Inconsistent way to locate filename when creating configuration --- Key: CONFIGURATION-216 URL: http://issues.apache.org/jira/browse/CONFIGURATION-216 Project: Commons Configuration Issue Type: Bug Environment: commons-configuration-1.3-dev Reporter: Gabriele Garuglieri Assigned To: Oliver Heger Priority: Minor Attachments: 216.patch There is a different behaviour locating the configuration file in classpath depending on the way it is set in the configuration class. For example assuming conf/conf1.properties exists in classpath: PropertiesConfiguration pc = new PropertiesConfiguration(conf/conf1.properties); gives org.apache.commons.configuration.ConfigurationException: Cannot locate configuration source conf1.properties while PropertiesConfiguration pc = new PropertiesConfiguration(); pc.setFileName(conf/conf1.properties); pc.load(); properly locate file in classpath and loads it. -- This message is automatically generated by JIRA. - If you think it was sent incorrectly contact one of the administrators: http://issues.apache.org/jira/secure/Administrators.jspa - For more information on JIRA, see: http://www.atlassian.com/software/jira - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
[jira] Resolved: (SANDBOX-71) [id] Sporadic test failures in TimeBasesAlphanumericIdentifierGeneratorTest
[ http://issues.apache.org/jira/browse/SANDBOX-71?page=all ] Joerg Schaible resolved SANDBOX-71. --- Fix Version/s: Nightly Builds Resolution: Fixed Fixed another test failing for forward time shifts. [id] Sporadic test failures in TimeBasesAlphanumericIdentifierGeneratorTest --- Key: SANDBOX-71 URL: http://issues.apache.org/jira/browse/SANDBOX-71 Project: Commons Sandbox Issue Type: Bug Components: Id Environment: Operating System: other Platform: All Reporter: Joerg Schaible Assigned To: Joerg Schaible Fix For: Nightly Builds Attachments: TimeBasedAIGTest.patch The unit tests for TimeBasesAlphanumericIdentifierGenerator fail with Gump sometimes for unknown reason. Unfortunately it seems, that the exactly test reports are unavailable. Nevertheless I suspect timing problems that interfere and may fail running the fixtures of the test within the same time slice. Therefore was in setUp() a sleep(50) call that might fail to create a unique operation environment for each test fixture depending on the OS/hardware environment. This synchronization has been replaced with an explicit loop waiting for the next time slice. -- This message is automatically generated by JIRA. - If you think it was sent incorrectly contact one of the administrators: http://issues.apache.org/jira/secure/Administrators.jspa - For more information on JIRA, see: http://www.atlassian.com/software/jira - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
[jira] Updated: (SANDBOX-169) Can`t attach patch to SANDBOX-150
[ http://issues.apache.org/jira/browse/SANDBOX-169?page=all ] Joerg Schaible updated SANDBOX-169: --- Summary: Can`t attach patch to SANDBOX-150 (was: Can`t attache patch to SENDBOX-150) Can`t attach patch to SANDBOX-150 - Key: SANDBOX-169 URL: http://issues.apache.org/jira/browse/SANDBOX-169 Project: Commons Sandbox Issue Type: Sub-task Components: JCI Reporter: Peter Konstantinov Attachments: jci-06-08-15.patch -- This message is automatically generated by JIRA. - If you think it was sent incorrectly contact one of the administrators: http://issues.apache.org/jira/secure/Administrators.jspa - For more information on JIRA, see: http://www.atlassian.com/software/jira - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
[jira] Reopened: (SANDBOX-150) [jci][GSOC] Status patchs
[ http://issues.apache.org/jira/browse/SANDBOX-150?page=all ] Joerg Schaible reopened SANDBOX-150: New patch by Peter ... see subtask SANDBOX-169 [jci][GSOC] Status patchs - Key: SANDBOX-150 URL: http://issues.apache.org/jira/browse/SANDBOX-150 Project: Commons Sandbox Issue Type: New Feature Components: JCI Reporter: Dmitriy Khayredinov Assigned To: Torsten Curdt Attachments: jci-06.07.06.patch, jci-14.06.06.patch -- This message is automatically generated by JIRA. - If you think it was sent incorrectly contact one of the administrators: http://issues.apache.org/jira/secure/Administrators.jspa - For more information on JIRA, see: http://www.atlassian.com/software/jira - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
[jira] Commented: (SANDBOX-169) Can`t attach patch to SANDBOX-150
[ http://issues.apache.org/jira/browse/SANDBOX-169?page=comments#action_12428093 ] Joerg Schaible commented on SANDBOX-169: The original issue was closed, therefore I was more surprised, that you still could add a new open subtask ;-) Can`t attach patch to SANDBOX-150 - Key: SANDBOX-169 URL: http://issues.apache.org/jira/browse/SANDBOX-169 Project: Commons Sandbox Issue Type: Sub-task Components: JCI Reporter: Peter Konstantinov Attachments: jci-06-08-15-2.patch, jci-06-08-15.patch -- This message is automatically generated by JIRA. - If you think it was sent incorrectly contact one of the administrators: http://issues.apache.org/jira/secure/Administrators.jspa - For more information on JIRA, see: http://www.atlassian.com/software/jira - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
[jira] Resolved: (SANDBOX-151) [ID] VersionFourGenerator.nextIdentifier fails in secure mode
[ http://issues.apache.org/jira/browse/SANDBOX-151?page=all ]
Joerg Schaible resolved SANDBOX-151.
Fix Version/s: Nightly Builds
Resolution: Fixed
Fixed in Subversion.
[ID] VersionFourGenerator.nextIdentifier fails in secure mode
-
Key: SANDBOX-151
URL: http://issues.apache.org/jira/browse/SANDBOX-151
Project: Commons Sandbox
Issue Type: Bug
Components: Id
Environment: This JIRA environment is horrible: If I am not logged in
I cannot report a bug (may be OK), but I am then on a page which just does
not tell me about authorization problems but offers me some other projects
where I could report!
Reporter: Martin Heitz
Assigned To: Joerg Schaible
Priority: Critical
Fix For: Nightly Builds
Generating secure ID only works on initialization, aftyerwards always the
same ID is returned.
Fix the wrong if-blocks, then also the third ID will be unique...:
private UUID nextUUID(boolean secure)
{
byte[] raw = new byte[UUID_BYTE_LENGTH];
if (secure) {
//Initialize the secure random if null.
if (secureRandom == null) {
try {
if (usePRNGPackage != null) {
secureRandom = SecureRandom.getInstance(usePRNG,
usePRNGPackage);
} else {
secureRandom = SecureRandom.getInstance(usePRNG);
}
} catch (NoSuchAlgorithmException nsae) {
nsae.printStackTrace();
secure = false; //Fail back to default PRNG/Random
} catch (NoSuchProviderException nspe) {
nspe.printStackTrace();
secure = false; //Fail back to default PRNG/Random
}
}
// fix by mattin
if (secureRandom != null) {
secureRandom.nextBytes(raw);
}
}
if (!secure) {
regularRandom.nextBytes(raw);
}
--
This message is automatically generated by JIRA.
-
If you think it was sent incorrectly contact one of the administrators:
http://issues.apache.org/jira/secure/Administrators.jspa
-
For more information on JIRA, see: http://www.atlassian.com/software/jira
-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
[jira] Commented: (IO-17) [io] delete in FileUtils sometimes fails on Windows
[ http://issues.apache.org/jira/browse/IO-17?page=comments#action_12420789 ] Joerg Schaible commented on IO-17: -- Same from me: Using System.gc() in a library method is a no-no! If you cannot delete the file, it simply means, someone did not close it. So that code should be fixed! [io] delete in FileUtils sometimes fails on Windows --- Key: IO-17 URL: http://issues.apache.org/jira/browse/IO-17 Project: Commons IO Type: Bug Versions: 1.0 Environment: Operating System: Windows XP Platform: PC Reporter: Wim Deblauwe Fix For: 1.3 The delete function in the FileUtils class will sometimes not delete a file or directory on windows. This is a known bug in the VM. Ant solves this by calling the GC explecitly and then wait some time. See http://cvs.apache.org/viewcvs.cgi/ant/src/main/org/apache/tools/ant/taskdefs/Delete.java?view=markup on how they do it. -- This message is automatically generated by JIRA. - If you think it was sent incorrectly contact one of the administrators: http://issues.apache.org/jira/secure/Administrators.jspa - For more information on JIRA, see: http://www.atlassian.com/software/jira - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
[jira] Reopened: (SANDBOX-71) [id] Sporadic test failures in TimeBasesAlphanumericIdentifierGeneratorTest
[ http://issues.apache.org/jira/browse/SANDBOX-71?page=all ] Joerg Schaible reopened SANDBOX-71: --- Assign To: Joerg Schaible Seems to manifest again on vmgump :-/ [id] Sporadic test failures in TimeBasesAlphanumericIdentifierGeneratorTest --- Key: SANDBOX-71 URL: http://issues.apache.org/jira/browse/SANDBOX-71 Project: Commons Sandbox Type: Bug Components: Id Environment: Operating System: other Platform: All Reporter: Joerg Schaible Assignee: Joerg Schaible Attachments: TimeBasedAIGTest.patch The unit tests for TimeBasesAlphanumericIdentifierGenerator fail with Gump sometimes for unknown reason. Unfortunately it seems, that the exactly test reports are unavailable. Nevertheless I suspect timing problems that interfere and may fail running the fixtures of the test within the same time slice. Therefore was in setUp() a sleep(50) call that might fail to create a unique operation environment for each test fixture depending on the OS/hardware environment. This synchronization has been replaced with an explicit loop waiting for the next time slice. -- This message is automatically generated by JIRA. - If you think it was sent incorrectly contact one of the administrators: http://issues.apache.org/jira/secure/Administrators.jspa - For more information on JIRA, see: http://www.atlassian.com/software/jira - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
[jira] Commented: (SANDBOX-71) [id] Sporadic test failures in TimeBasesAlphanumericIdentifierGeneratorTest
[ http://issues.apache.org/jira/browse/SANDBOX-71?page=comments#action_12419325 ] Joerg Schaible commented on SANDBOX-71: --- Hi Martin, thanks for the comment, but the link is no longer valid. If you have the document still, can you attach it here? In fact the TimeBasedAIG will be infected by back shifts in time. Since the clock of my machine at home also is aggressivly synchronized, the implementation is meanwhile quite robust, but especially if sudden time corrections appear, the impl will throw an exception, since it can no longer guarantee unique IDs. It will work though, if a time synchronization daemon runs that adjust the time smoothly (even back shifts). [id] Sporadic test failures in TimeBasesAlphanumericIdentifierGeneratorTest --- Key: SANDBOX-71 URL: http://issues.apache.org/jira/browse/SANDBOX-71 Project: Commons Sandbox Type: Bug Components: Id Environment: Operating System: other Platform: All Reporter: Joerg Schaible Assignee: Joerg Schaible Attachments: TimeBasedAIGTest.patch The unit tests for TimeBasesAlphanumericIdentifierGenerator fail with Gump sometimes for unknown reason. Unfortunately it seems, that the exactly test reports are unavailable. Nevertheless I suspect timing problems that interfere and may fail running the fixtures of the test within the same time slice. Therefore was in setUp() a sleep(50) call that might fail to create a unique operation environment for each test fixture depending on the OS/hardware environment. This synchronization has been replaced with an explicit loop waiting for the next time slice. -- This message is automatically generated by JIRA. - If you think it was sent incorrectly contact one of the administrators: http://issues.apache.org/jira/secure/Administrators.jspa - For more information on JIRA, see: http://www.atlassian.com/software/jira - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
