[jira] [Commented] (VFS-500) VFSClassLoader.findResources missing
[ https://issues.apache.org/jira/browse/VFS-500?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=15301288#comment-15301288 ] Josh Elser commented on VFS-500: bq. The current fix does not work for the IBM JDKs, the test is failing. [~joehni], just to clarify: the fix actually does not work on IBM JDKs, or the test for the fix doesn't work on IBM JDKs? Thanks. > VFSClassLoader.findResources missing > > > Key: VFS-500 > URL: https://issues.apache.org/jira/browse/VFS-500 > Project: Commons VFS > Issue Type: New Feature >Affects Versions: 2.0 >Reporter: Bernd Eckenfels >Assignee: Bernd Eckenfels >Priority: Minor > Fix For: 2.2 > > Attachments: vfs-500-gg.diff > > > the VFSClassLoader.findResources(String) method is a dummy implementation > returning an empty Enumeration. > I have a working implementation and will support the patch for it, this is > the JIRA to track it. -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Commented] (BEANUTILS-486) DateConverter fails when pattern and locale are set
[
https://issues.apache.org/jira/browse/BEANUTILS-486?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=15300959#comment-15300959
]
Andrew Rucker Jones commented on BEANUTILS-486:
---
I hadn't really wanted to, having enough to do of my own, but I sat down to the
task anyway, and in so doing, I discovered this is more likely a mere
documentation deficiency. What I want to do is done in DateLocaleConverter,
which I had overlooked. This behavior is documented fairly clearly in the
Javadoc for DateConverter: "This implementation can be configured to handle
conversion either by using a Locale's default format or by specifying a set of
format patterns [. . .]". The problem is, this very same Javadoc references the
documentation from the base class: "See the DateTimeConverter documentation for
further details." The base class, DateTimeConverter, is very specific about the
behavior to be expected of derived classes, which includes using a specified
pattern and a specified locale, going so far as to include pseudocode for this
use case. The documentation in the base class appears to be in error, or
perhaps the documentation in the derived class should be more explicit about
the fact that it does not support this intended behavior.
This ticket may be closed once the documentation is corrected.
> DateConverter fails when pattern and locale are set
> ---
>
> Key: BEANUTILS-486
> URL: https://issues.apache.org/jira/browse/BEANUTILS-486
> Project: Commons BeanUtils
> Issue Type: Bug
> Components: Locale BeanUtils / Converters
>Affects Versions: 1.9.2
> Environment: MacOS X 10.11.4
> Java 1.8.0_11
> Default locale: de_DE
>Reporter: Andrew Rucker Jones
> Labels: easyfix
>
> When using a DateConverter or any of the date conversion classes, setting an
> explicit pattern causes the locale to be ignored. The converter seems to
> think that the locale is only useful for finding the default pattern for the
> locale, but that's not true, as the following code illustrates.
> {code:java}
> public static void main(String[] args) {
> SimpleDateFormat sdf = new SimpleDateFormat("MMM dd, ", new
> Locale("en_US"));
> ParsePosition pos = new ParsePosition(0);
> Date result = sdf.parse("Dec 15, 1978", pos);
> System.out.println(result); // Prints "Fri Dec 15 00:00:00 CET 1978"
>
> // Equivalent code should return the same result as the last section
> DateConverter c = new DateConverter();
> c.setPattern("MMM dd, ");
> c.setLocale(new Locale("en_US"));
> c.convert(Date.class, "Dec 15, 1978"); // Throws ConversionException
> }
> {code}
> I'm expanding opencsv (opencsv.sourceforge.net), and this bug is breaking my
> code. I would really appreciate a speedy resolution.
--
This message was sent by Atlassian JIRA
(v6.3.4#6332)
[jira] [Updated] (BEANUTILS-486) DateConverter fails when pattern and locale are set
[
https://issues.apache.org/jira/browse/BEANUTILS-486?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Andrew Rucker Jones updated BEANUTILS-486:
--
Labels: documentation (was: easyfix)
> DateConverter fails when pattern and locale are set
> ---
>
> Key: BEANUTILS-486
> URL: https://issues.apache.org/jira/browse/BEANUTILS-486
> Project: Commons BeanUtils
> Issue Type: Bug
> Components: Locale BeanUtils / Converters
>Affects Versions: 1.9.2
> Environment: MacOS X 10.11.4
> Java 1.8.0_11
> Default locale: de_DE
>Reporter: Andrew Rucker Jones
> Labels: documentation
>
> When using a DateConverter or any of the date conversion classes, setting an
> explicit pattern causes the locale to be ignored. The converter seems to
> think that the locale is only useful for finding the default pattern for the
> locale, but that's not true, as the following code illustrates.
> {code:java}
> public static void main(String[] args) {
> SimpleDateFormat sdf = new SimpleDateFormat("MMM dd, ", new
> Locale("en_US"));
> ParsePosition pos = new ParsePosition(0);
> Date result = sdf.parse("Dec 15, 1978", pos);
> System.out.println(result); // Prints "Fri Dec 15 00:00:00 CET 1978"
>
> // Equivalent code should return the same result as the last section
> DateConverter c = new DateConverter();
> c.setPattern("MMM dd, ");
> c.setLocale(new Locale("en_US"));
> c.convert(Date.class, "Dec 15, 1978"); // Throws ConversionException
> }
> {code}
> I'm expanding opencsv (opencsv.sourceforge.net), and this bug is breaking my
> code. I would really appreciate a speedy resolution.
--
This message was sent by Atlassian JIRA
(v6.3.4#6332)
[jira] [Created] (CRYPTO-63) Add JNA binding
Hendrik Saly created CRYPTO-63: -- Summary: Add JNA binding Key: CRYPTO-63 URL: https://issues.apache.org/jira/browse/CRYPTO-63 Project: Commons Crypto Issue Type: Improvement Reporter: Hendrik Saly Needs benchmarking before merge. PR https://github.com/apache/commons-crypto/pull/47 -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Commented] (CRYPTO-61) possible NPE in OpensslCryptoRandom if OpensslCryptoRandomNative.nextRandBytes fails
[ https://issues.apache.org/jira/browse/CRYPTO-61?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=15300727#comment-15300727 ] Hendrik Saly commented on CRYPTO-61: ups, mixed up some PR's, sorry for this one here its only the first commit of PR 45 -> https://github.com/apache/commons-crypto/pull/45/commits/71496ee64d550781c741f24f9a4f995d42afd95f > possible NPE in OpensslCryptoRandom if > OpensslCryptoRandomNative.nextRandBytes fails > > > Key: CRYPTO-61 > URL: https://issues.apache.org/jira/browse/CRYPTO-61 > Project: Commons Crypto > Issue Type: Bug >Reporter: Hendrik Saly > > "fallback" could be null in OpensslCryptoRandom.nextBytes(byte[]) -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Commented] (CRYPTO-62) Add multithreaded related tests and javadoc comments
[ https://issues.apache.org/jira/browse/CRYPTO-62?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=15300721#comment-15300721 ] Hendrik Saly commented on CRYPTO-62: PR https://github.com/apache/commons-crypto/pull/46 > Add multithreaded related tests and javadoc comments > > > Key: CRYPTO-62 > URL: https://issues.apache.org/jira/browse/CRYPTO-62 > Project: Commons Crypto > Issue Type: Improvement >Reporter: Hendrik Saly >Priority: Minor > > Add multithreaded related tests for random number generation and javadoc > comments to make clear that the chipers are NOT thread-safe -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Created] (CRYPTO-62) Add multithreaded related tests and javadoc comments
Hendrik Saly created CRYPTO-62: -- Summary: Add multithreaded related tests and javadoc comments Key: CRYPTO-62 URL: https://issues.apache.org/jira/browse/CRYPTO-62 Project: Commons Crypto Issue Type: Improvement Reporter: Hendrik Saly Priority: Minor Add multithreaded related tests for random number generation and javadoc comments to make clear that the chipers are NOT thread-safe -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Commented] (CRYPTO-61) possible NPE in OpensslCryptoRandom if OpensslCryptoRandomNative.nextRandBytes fails
[ https://issues.apache.org/jira/browse/CRYPTO-61?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=15300649#comment-15300649 ] Hendrik Saly commented on CRYPTO-61: PR https://github.com/apache/commons-crypto/pull/45 patch https://patch-diff.githubusercontent.com/raw/apache/commons-crypto/pull/45.patch > possible NPE in OpensslCryptoRandom if > OpensslCryptoRandomNative.nextRandBytes fails > > > Key: CRYPTO-61 > URL: https://issues.apache.org/jira/browse/CRYPTO-61 > Project: Commons Crypto > Issue Type: Bug >Reporter: Hendrik Saly > > "fallback" could be null in OpensslCryptoRandom.nextBytes(byte[]) -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Created] (CRYPTO-61) possible NPE in OpensslCryptoRandom if OpensslCryptoRandomNative.nextRandBytes fails
Hendrik Saly created CRYPTO-61: -- Summary: possible NPE in OpensslCryptoRandom if OpensslCryptoRandomNative.nextRandBytes fails Key: CRYPTO-61 URL: https://issues.apache.org/jira/browse/CRYPTO-61 Project: Commons Crypto Issue Type: Bug Reporter: Hendrik Saly "fallback" could be null in OpensslCryptoRandom.nextBytes(byte[]) -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[GitHub] commons-lang pull request: General cleanup
Github user pivovarit closed the pull request at: https://github.com/apache/commons-lang/pull/127 --- If your project is set up for it, you can reply to this email and have your reply appear on GitHub as well. If your project does not have this feature enabled and wishes so, or if the feature is enabled but not working, please contact infrastructure at infrastruct...@apache.org or file a JIRA ticket with INFRA. ---
[jira] [Created] (COMPRESS-357) BZip2CompressorOutputStream can affect output stream incorrectly
Richard Shapiro created COMPRESS-357: Summary: BZip2CompressorOutputStream can affect output stream incorrectly Key: COMPRESS-357 URL: https://issues.apache.org/jira/browse/COMPRESS-357 Project: Commons Compress Issue Type: Bug Components: Compressors Affects Versions: 1.11, 1.9 Environment: multithreaded Reporter: Richard Shapiro BZip2CompressorOutputStream has an unsynchronized finished() method, and an unsynchronized finalize method. Finish checks to see if the output stream is null, and if it is not it calls various methods, some of which write to the output stream. Now, consider something like this sequence. BZip2OutputStream s = ... ... s.close(); s = null; After the s = null, the stream is garbage. At some point the garbage collector call finalize(), which calls finish(). But, since the GC may be on a different thread, there is no guarantee that the assignment this.out = null in finish() has actually been made visible to the GC thread, which results in bad data in the output stream. This is not a theoretical problem; In a part of a large project I'm working on, this happens about 2% of the time. The fixes are simple 1) synchronize finish() or 2) don't call finish from finalize(). A workaround is to derive a class and override the finalize() method. -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Commented] (DAEMON-348) Clearing the "Thread Stack Size" field leaves service unstartable
[
https://issues.apache.org/jira/browse/DAEMON-348?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=15299845#comment-15299845
]
Rod Widdowson commented on DAEMON-348:
--
> So are you saying that the code should remove the JvmSs entry if the
> ThreadStackSize (TSS) field is emptied?
Absolutely. I brought my customer's machine back to life by doing just that.
> I assume it does not create the entry if the TSS field is empty on initial
> creation.
Correct. It only gets populated when you change it.
> I don't have a Windows system handy at present to check
I have _loads_ of windows VMs lieing about if you need me to run tests.
/Rod
> Clearing the "Thread Stack Size" field leaves service unstartable
> -
>
> Key: DAEMON-348
> URL: https://issues.apache.org/jira/browse/DAEMON-348
> Project: Commons Daemon
> Issue Type: Bug
> Components: Procrun
>Affects Versions: 1.0.15
> Environment: Windows7 x86
>Reporter: Rod Widdowson
>
> Just diagnosed an issue with a customer in which the java [process was
> unrunnable). This was because
> {{HKEY_LOCAL_MACHINE\SOFTWARE\Apache Software Foundation\Procrun
> 2.0\shibd_idp\Parameters\Java\JvmSs}} was zero, (where {{shibd_idp}} is the
> service.
> I managed to reproduce this behavior by
> * starting shibd_idpw (a.k.a prunmgr.exe)
> * modifying Thread Stack Size to be something
> * (verify with regedit)
> * clear the Thread Stack Size field
> * JvmSs is now zero
--
This message was sent by Atlassian JIRA
(v6.3.4#6332)
[jira] [Commented] (DAEMON-348) Clearing the "Thread Stack Size" field leaves service unstartable
[
https://issues.apache.org/jira/browse/DAEMON-348?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=15299821#comment-15299821
]
Sebb commented on DAEMON-348:
-
So are you saying that the code should remove the JvmSs entry if the
ThreadStackSize (TSS) field is emptied?
Or some other behaviour?
I assume it does not create the entry if the TSS field is empty on initial
creation.
I don't have a Windows system handy at present to check.
> Clearing the "Thread Stack Size" field leaves service unstartable
> -
>
> Key: DAEMON-348
> URL: https://issues.apache.org/jira/browse/DAEMON-348
> Project: Commons Daemon
> Issue Type: Bug
> Components: Procrun
>Affects Versions: 1.0.15
> Environment: Windows7 x86
>Reporter: Rod Widdowson
>
> Just diagnosed an issue with a customer in which the java [process was
> unrunnable). This was because
> {{HKEY_LOCAL_MACHINE\SOFTWARE\Apache Software Foundation\Procrun
> 2.0\shibd_idp\Parameters\Java\JvmSs}} was zero, (where {{shibd_idp}} is the
> service.
> I managed to reproduce this behavior by
> * starting shibd_idpw (a.k.a prunmgr.exe)
> * modifying Thread Stack Size to be something
> * (verify with regedit)
> * clear the Thread Stack Size field
> * JvmSs is now zero
--
This message was sent by Atlassian JIRA
(v6.3.4#6332)
[jira] [Updated] (DAEMON-348) Clearing the "Thread Stack Size" field leaves service unstartable
[
https://issues.apache.org/jira/browse/DAEMON-348?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Rod Widdowson updated DAEMON-348:
-
Description:
Just diagnosed an issue with a customer in which the java [process was
unrunnable). This was because
{{HKEY_LOCAL_MACHINE\SOFTWARE\Apache Software Foundation\Procrun
2.0\shibd_idp\Parameters\Java\JvmSs}} was zero, (where {{shibd_idp}} is the
service.
I managed to reproduce this behavior by
* starting shibd_idpw (a.k.a prunmgr.exe)
* modifying Thread Stack Size to be something
* (verify with regedit)
* clear the Thread Stack Size field
* JvmSs is now zero
was:
Just diagnosed an issue with a customer in which the java [process was
unrunnable). This was because {{ HKEY_LOCAL_MACHINE\SOFTWARE\Apache Software
Foundation\Procrun 2.0\shibd_idp\Parameters\Java\JvmSs}} was zero, (where
{{shibd_idp}} is the service.
I managed to reproduce this behavior by
* starting shibd_idpw (a.k.a prunmgr.exe)
* modifying Thread Stack Size to be something
* (verify with regedit)
* clear the Thread Stack Size field
* JvmSs is now zero
> Clearing the "Thread Stack Size" field leaves service unstartable
> -
>
> Key: DAEMON-348
> URL: https://issues.apache.org/jira/browse/DAEMON-348
> Project: Commons Daemon
> Issue Type: Bug
> Components: Procrun
>Affects Versions: 1.0.15
> Environment: Windows7 x86
>Reporter: Rod Widdowson
>
> Just diagnosed an issue with a customer in which the java [process was
> unrunnable). This was because
> {{HKEY_LOCAL_MACHINE\SOFTWARE\Apache Software Foundation\Procrun
> 2.0\shibd_idp\Parameters\Java\JvmSs}} was zero, (where {{shibd_idp}} is the
> service.
> I managed to reproduce this behavior by
> * starting shibd_idpw (a.k.a prunmgr.exe)
> * modifying Thread Stack Size to be something
> * (verify with regedit)
> * clear the Thread Stack Size field
> * JvmSs is now zero
--
This message was sent by Atlassian JIRA
(v6.3.4#6332)
[jira] [Updated] (DAEMON-348) Clearing the "Thread Stack Size" field leaves service unstartable
[
https://issues.apache.org/jira/browse/DAEMON-348?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Rod Widdowson updated DAEMON-348:
-
Description:
Just diagnosed an issue with a customer in which the java [process was
unrunnable). This was because {{ HKEY_LOCAL_MACHINE\SOFTWARE\Apache Software
Foundation\Procrun 2.0\shibd_idp\Parameters\Java\JvmSs}} was zero, (where
{{shibd_idp}} is the service.
I managed to reproduce this behavior by
* starting shibd_idpw (a.k.a prunmgr.exe)
* modifying Thread Stack Size to be something
* (verify with regedit)
* clear the Thread Stack Size field
* JvmSs is now zero
was:
Just diagnosed an issue with a customer in which the java [process was
unrunnable). This was because {{ HKEY_LOCAL_MACHINE\SOFTWARE\Apache Software
Foundation\Procrun 2.0\shibd_idp\Parameters\Java\JvmSs}} was zero, (where
{{shibd_idp}} is the service.
I managed to reproduce this behavior by
+ starting shibd_idpw (a.k.a prunmgr.exe)
+ modifying Thread Stack Size to be something
+ (verify with regedit)
+ clear the Thread Stack Size field
+ JvmSs is now zero
> Clearing the "Thread Stack Size" field leaves service unstartable
> -
>
> Key: DAEMON-348
> URL: https://issues.apache.org/jira/browse/DAEMON-348
> Project: Commons Daemon
> Issue Type: Bug
> Components: Procrun
>Affects Versions: 1.0.15
> Environment: Windows7 x86
>Reporter: Rod Widdowson
>
> Just diagnosed an issue with a customer in which the java [process was
> unrunnable). This was because {{ HKEY_LOCAL_MACHINE\SOFTWARE\Apache Software
> Foundation\Procrun 2.0\shibd_idp\Parameters\Java\JvmSs}} was zero, (where
> {{shibd_idp}} is the service.
> I managed to reproduce this behavior by
> * starting shibd_idpw (a.k.a prunmgr.exe)
> * modifying Thread Stack Size to be something
> * (verify with regedit)
> * clear the Thread Stack Size field
> * JvmSs is now zero
--
This message was sent by Atlassian JIRA
(v6.3.4#6332)
[jira] [Created] (DAEMON-348) Clearing the "Thread Stack Size" field leaves service unstartable
Rod Widdowson created DAEMON-348:
Summary: Clearing the "Thread Stack Size" field leaves service
unstartable
Key: DAEMON-348
URL: https://issues.apache.org/jira/browse/DAEMON-348
Project: Commons Daemon
Issue Type: Bug
Components: Procrun
Affects Versions: 1.0.15
Environment: Windows7 x86
Reporter: Rod Widdowson
Just diagnosed an issue with a customer in which the java [process was
unrunnable). This was because {{ HKEY_LOCAL_MACHINE\SOFTWARE\Apache Software
Foundation\Procrun 2.0\shibd_idp\Parameters\Java\JvmSs}} was zero, (where
{{shibd_idp}} is the service.
I managed to reproduce this behavior by
+ starting shibd_idpw (a.k.a prunmgr.exe)
+ modifying Thread Stack Size to be something
+ (verify with regedit)
+ clear the Thread Stack Size field
+ JvmSs is now zero
--
This message was sent by Atlassian JIRA
(v6.3.4#6332)
[jira] [Commented] (BEANUTILS-486) DateConverter fails when pattern and locale are set
[
https://issues.apache.org/jira/browse/BEANUTILS-486?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=15299578#comment-15299578
]
Gary Gregory commented on BEANUTILS-486:
Patches welcome, with unit tests of course! :-)
> DateConverter fails when pattern and locale are set
> ---
>
> Key: BEANUTILS-486
> URL: https://issues.apache.org/jira/browse/BEANUTILS-486
> Project: Commons BeanUtils
> Issue Type: Bug
> Components: Locale BeanUtils / Converters
>Affects Versions: 1.9.2
> Environment: MacOS X 10.11.4
> Java 1.8.0_11
> Default locale: de_DE
>Reporter: Andrew Rucker Jones
> Labels: easyfix
>
> When using a DateConverter or any of the date conversion classes, setting an
> explicit pattern causes the locale to be ignored. The converter seems to
> think that the locale is only useful for finding the default pattern for the
> locale, but that's not true, as the following code illustrates.
> {code:java}
> public static void main(String[] args) {
> SimpleDateFormat sdf = new SimpleDateFormat("MMM dd, ", new
> Locale("en_US"));
> ParsePosition pos = new ParsePosition(0);
> Date result = sdf.parse("Dec 15, 1978", pos);
> System.out.println(result); // Prints "Fri Dec 15 00:00:00 CET 1978"
>
> // Equivalent code should return the same result as the last section
> DateConverter c = new DateConverter();
> c.setPattern("MMM dd, ");
> c.setLocale(new Locale("en_US"));
> c.convert(Date.class, "Dec 15, 1978"); // Throws ConversionException
> }
> {code}
> I'm expanding opencsv (opencsv.sourceforge.net), and this bug is breaking my
> code. I would really appreciate a speedy resolution.
--
This message was sent by Atlassian JIRA
(v6.3.4#6332)
[jira] [Updated] (BEANUTILS-486) DateConverter fails when pattern and locale are set
[
https://issues.apache.org/jira/browse/BEANUTILS-486?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Gary Gregory updated BEANUTILS-486:
---
Description:
When using a DateConverter or any of the date conversion classes, setting an
explicit pattern causes the locale to be ignored. The converter seems to think
that the locale is only useful for finding the default pattern for the locale,
but that's not true, as the following code illustrates.
{code:java}
public static void main(String[] args) {
SimpleDateFormat sdf = new SimpleDateFormat("MMM dd, ", new
Locale("en_US"));
ParsePosition pos = new ParsePosition(0);
Date result = sdf.parse("Dec 15, 1978", pos);
System.out.println(result); // Prints "Fri Dec 15 00:00:00 CET 1978"
// Equivalent code should return the same result as the last section
DateConverter c = new DateConverter();
c.setPattern("MMM dd, ");
c.setLocale(new Locale("en_US"));
c.convert(Date.class, "Dec 15, 1978"); // Throws ConversionException
}
{code}
I'm expanding opencsv (opencsv.sourceforge.net), and this bug is breaking my
code. I would really appreciate a speedy resolution.
was:
When using a DateConverter or any of the date conversion classes, setting an
explicit pattern causes the locale to be ignored. The converter seems to think
that the locale is only useful for finding the default pattern for the locale,
but that's not true, as the following code illustrates.
public static void main(String[] args) {
SimpleDateFormat sdf = new SimpleDateFormat("MMM dd, ", new
Locale("en_US"));
ParsePosition pos = new ParsePosition(0);
Date result = sdf.parse("Dec 15, 1978", pos);
System.out.println(result); // Prints "Fri Dec 15 00:00:00 CET 1978"
// Equivalent code should return the same result as the last section
DateConverter c = new DateConverter();
c.setPattern("MMM dd, ");
c.setLocale(new Locale("en_US"));
c.convert(Date.class, "Dec 15, 1978"); // Throws ConversionException
}
I'm expanding opencsv (opencsv.sourceforge.net), and this bug is breaking my
code. I would really appreciate a speedy resolution.
> DateConverter fails when pattern and locale are set
> ---
>
> Key: BEANUTILS-486
> URL: https://issues.apache.org/jira/browse/BEANUTILS-486
> Project: Commons BeanUtils
> Issue Type: Bug
> Components: Locale BeanUtils / Converters
>Affects Versions: 1.9.2
> Environment: MacOS X 10.11.4
> Java 1.8.0_11
> Default locale: de_DE
>Reporter: Andrew Rucker Jones
> Labels: easyfix
>
> When using a DateConverter or any of the date conversion classes, setting an
> explicit pattern causes the locale to be ignored. The converter seems to
> think that the locale is only useful for finding the default pattern for the
> locale, but that's not true, as the following code illustrates.
> {code:java}
> public static void main(String[] args) {
> SimpleDateFormat sdf = new SimpleDateFormat("MMM dd, ", new
> Locale("en_US"));
> ParsePosition pos = new ParsePosition(0);
> Date result = sdf.parse("Dec 15, 1978", pos);
> System.out.println(result); // Prints "Fri Dec 15 00:00:00 CET 1978"
>
> // Equivalent code should return the same result as the last section
> DateConverter c = new DateConverter();
> c.setPattern("MMM dd, ");
> c.setLocale(new Locale("en_US"));
> c.convert(Date.class, "Dec 15, 1978"); // Throws ConversionException
> }
> {code}
> I'm expanding opencsv (opencsv.sourceforge.net), and this bug is breaking my
> code. I would really appreciate a speedy resolution.
--
This message was sent by Atlassian JIRA
(v6.3.4#6332)
[jira] [Commented] (BCEL-271) FCONST pattern does not include FCONST_2
[
https://issues.apache.org/jira/browse/BCEL-271?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=15299574#comment-15299574
]
Gary Gregory commented on BCEL-271:
---
Patches welcome, with unit tests of course :-)
> FCONST pattern does not include FCONST_2
>
>
> Key: BCEL-271
> URL: https://issues.apache.org/jira/browse/BCEL-271
> Project: Commons BCEL
> Issue Type: Bug
>Affects Versions: 6.0
>Reporter: Daniel Gavrilov
>Priority: Minor
>
> The {{FCONST}} pattern in
> [InstructionFinder.java:356|https://commons.apache.org/proper/commons-bcel/apidocs/src-html/org/apache/bcel/util/InstructionFinder.html#line.356]
> should include {{FCONST_2}}.
--
This message was sent by Atlassian JIRA
(v6.3.4#6332)
[jira] [Resolved] (CRYPTO-57) Fix build on Mac OS
[ https://issues.apache.org/jira/browse/CRYPTO-57?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Dapeng Sun resolved CRYPTO-57. -- Resolution: Fixed Assignee: Benedikt Ritter > Fix build on Mac OS > --- > > Key: CRYPTO-57 > URL: https://issues.apache.org/jira/browse/CRYPTO-57 > Project: Commons Crypto > Issue Type: Improvement > Components: Build >Affects Versions: 1.0.0 >Reporter: Benedikt Ritter >Assignee: Benedikt Ritter > Fix For: 1.0.0 > > Attachments: openssl_build_mac.sh > > > Fix build on Mac OS, by explicitly adding OpenSSL 101 libraries to > Makefile.common. See https://github.com/apache/commons-crypto/pull/42 -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Commented] (CRYPTO-57) Fix build on Mac OS
[ https://issues.apache.org/jira/browse/CRYPTO-57?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=15299531#comment-15299531 ] Dapeng Sun commented on CRYPTO-57: -- Thank [~salyh] and [~britter], https://github.com/apache/commons-crypto/pull/42 is merged, please let me know if you still have any issue > Fix build on Mac OS > --- > > Key: CRYPTO-57 > URL: https://issues.apache.org/jira/browse/CRYPTO-57 > Project: Commons Crypto > Issue Type: Improvement > Components: Build >Affects Versions: 1.0.0 >Reporter: Benedikt Ritter > Fix For: 1.0.0 > > Attachments: openssl_build_mac.sh > > > Fix build on Mac OS, by explicitly adding OpenSSL 101 libraries to > Makefile.common. See https://github.com/apache/commons-crypto/pull/42 -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Commented] (LANG-1237) String Split For Fixed-Length Strings
[
https://issues.apache.org/jira/browse/LANG-1237?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=15299525#comment-15299525
]
Loic Guibert commented on LANG-1237:
This feature is similar (but not same) with those in the LANG-1124 : Add split
by length methods in StringUtils.
I open it like an year ago, and there is a discussion on it.
I think we can group the discussions and remarks onto these
features to get homogeneous behaviors.
> String Split For Fixed-Length Strings
> -
>
> Key: LANG-1237
> URL: https://issues.apache.org/jira/browse/LANG-1237
> Project: Commons Lang
> Issue Type: New Feature
> Components: lang.text.*
>Reporter: BELUGA BEHR
>
> Create a StringSplit method that splits on defined boundaries.
> {code:java}
> /**
> * Used for fixed-length string formats
> * splitOnBoundary("HelloBigWorld", 4);
> * Returns ["Hello","BigWorld"]
> *
> * splitOnBoundary("HelloBigWorld", 4, 7);
> * Returns ["Hello","Big","World"]
> */
> String[] splitOnBoundary(String str, int... boundary);
> {code}
--
This message was sent by Atlassian JIRA
(v6.3.4#6332)
