[jira] [Commented] (LANG-1300) Clarify or improve behaviour of int-based methods in StringUtils

2017-03-15 Thread ASF GitHub Bot (JIRA) 

[ 
https://issues.apache.org/jira/browse/LANG-1300?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=15927416#comment-15927416
 ] 

ASF GitHub Bot commented on LANG-1300:
--

Github user coveralls commented on the issue:

https://github.com/apache/commons-lang/pull/251
  

[![Coverage 
Status](https://coveralls.io/builds/10618870/badge)](https://coveralls.io/builds/10618870)

Coverage increased (+0.05%) to 94.585% when pulling 
**b521820b23c45fd068618d10955eceed48801eff on 
MarkDacek:Lang1300CharSequenceUtilsChange** into 
**6597c196521af500feef7a02610727eafa7ec1dc on apache:master**.



> Clarify or improve behaviour of int-based methods in StringUtils
> 
>
> Key: LANG-1300
> URL: https://issues.apache.org/jira/browse/LANG-1300
> Project: Commons Lang
>  Issue Type: Improvement
>  Components: lang.*
>Affects Versions: 3.5
>Reporter: Duncan Jones
>Priority: Minor
> Fix For: Discussion
>
>
> The following methods use an {{int}} to represent a search character:
> {code:java}
> boolean contains(final CharSequence seq, final int searchChar)
> int indexOf(final CharSequence seq, final int searchChar)
> int indexOf(final CharSequence seq, final int searchChar, final int startPos)
> int lastIndexOf(final CharSequence seq, final int searchChar)
> int lastIndexOf(final CharSequence seq, final int searchChar, final int 
> startPos)
> {code}
> When I see an {{int}} representing a character, I tend to assume the method 
> can handle supplementary characters. However, the current behaviour of these 
> methods depends upon whether the {{CharSequence}} is a {{String}} or not.
> {code:java}
> StringBuilder builder = new StringBuilder();
> builder.appendCodePoint(0x2070E);
> System.out.println(StringUtils.lastIndexOf(builder, 0x2070E)); // -1
> System.out.println(StringUtils.lastIndexOf(builder.toString(), 0x2070E)); // 0
> {code}
> The Javadoc for these methods are ambiguous on this point, stating:
> {quote}
> This method uses {{String.lastIndexOf(int)}} if possible.
> {quote}
> I think we should consider updating the {{CharSequenceUtils}} methods used by 
> this class to convert all {{CharSequence}} parameters to strings, enabling 
> full code point support. The docs could be updated to make this crystal clear.
> There is a question of whether this breaks backwards compatibility.



--
This message was sent by Atlassian JIRA
(v6.3.15#6346)

[GitHub] commons-lang issue #251: LANG-1300: Change CharSequenceUtils to support supp...

2017-03-15 Thread coveralls 
Github user coveralls commented on the issue:

https://github.com/apache/commons-lang/pull/251
  

[![Coverage 
Status](https://coveralls.io/builds/10618870/badge)](https://coveralls.io/builds/10618870)

Coverage increased (+0.05%) to 94.585% when pulling 
**b521820b23c45fd068618d10955eceed48801eff on 
MarkDacek:Lang1300CharSequenceUtilsChange** into 
**6597c196521af500feef7a02610727eafa7ec1dc on apache:master**.



---
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] [Resolved] (EMAIL-167) DataSourceClassPathResolver doesn't close InputStream when resolving resources

2017-03-15 Thread Sebb (JIRA) 

 [ 
https://issues.apache.org/jira/browse/EMAIL-167?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
 ]

Sebb resolved EMAIL-167.

   Resolution: Fixed
Fix Version/s: 1.5

Thanks for the report and patch; applied:

URL: http://svn.apache.org/viewvc?rev=1787115=rev
Log:
EMAIL-167 DataSourceClassPathResolver doesn't close InputStream when resolving 
resources

Modified:
commons/proper/email/trunk/src/changes/changes.xml

commons/proper/email/trunk/src/main/java/org/apache/commons/mail/resolver/DataSourceClassPathResolver.java



> DataSourceClassPathResolver doesn't close InputStream when resolving resources
> --
>
> Key: EMAIL-167
> URL: https://issues.apache.org/jira/browse/EMAIL-167
> Project: Commons Email
>  Issue Type: Bug
>Affects Versions: 1.4
>Reporter: Lucian Burja
> Fix For: 1.5
>
> Attachments: EMAIL-167-close-input-stream.patch
>
>
> DataSourceClassPathResolver opens an InputStream (via 
> .class.getResourceAsStream) to read a resource into a ByteArrayDataSource, 
> but never closes it:
> {code}
> public DataSource resolve(final String resourceLocation, final boolean 
> isLenient) throws IOException
> {
> ...
> final InputStream is = 
> DataSourceClassPathResolver.class.getResourceAsStream(resourceName);
> if (is != null)
> {
> final ByteArrayDataSource ds = new 
> ByteArrayDataSource(is, mimeType);
> // EMAIL-125: set the name of the DataSource to the 
> normalized resource URL
> // similar to other DataSource implementations, e.g. 
> FileDataSource, URLDataSource
> 
> ds.setName(DataSourceClassPathResolver.class.getResource(resourceName).toString());
> result = ds;
> }
> {code}
> The 'is' variable above should be closed in a try ... finally



--
This message was sent by Atlassian JIRA
(v6.3.15#6346)

[GitHub] commons-lang issue #231: Evaluate Architecure

2017-03-15 Thread sebbASF 
Github user sebbASF commented on the issue:

https://github.com/apache/commons-lang/pull/231
  
I thought the idea was to move the isXXX methods to the Processor class.

You could then say
```
Processor processor = ArchUtils.getProcessor();
processor.is32Bit();
processor.isPPC();
etc.
```



---
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.
---

[GitHub] commons-lang pull request #231: Evaluate Architecure

2017-03-15 Thread sebbASF 
Github user sebbASF commented on a diff in the pull request:

https://github.com/apache/commons-lang/pull/231#discussion_r106312243
  
--- Diff: src/main/java/org/apache/commons/lang3/ArchUtils.java ---
@@ -0,0 +1,155 @@
+/*
+ * Licensed to the Apache Software Foundation (ASF) under one or more
+ * contributor license agreements.  See the NOTICE file distributed with
+ * this work for additional information regarding copyright ownership.
+ * The ASF licenses this file to You under the Apache License, Version 2.0
+ * (the "License"); you may not use this file except in compliance with
+ * the License.  You may obtain a copy of the License at
+ *
+ *  http://www.apache.org/licenses/LICENSE-2.0
+ *
+ * Unless required by applicable law or agreed to in writing, software
+ * distributed under the License is distributed on an "AS IS" BASIS,
+ * WITHOUT WARRANTIES OR CONDITIONS OF ANY KIND, either express or implied.
+ * See the License for the specific language governing permissions and
+ * limitations under the License.
+ */
+package org.apache.commons.lang3;
+
+import org.apache.commons.lang3.arch.Processor;
+import org.apache.commons.lang3.arch.ProcessorArch;
+import org.apache.commons.lang3.arch.ProcessorType;
+
+import java.util.HashMap;
+import java.util.List;
+import java.util.Map;
+
+/**
+ * An utility class for the os.arch System Property. The class defines 
methods for
+ * identifying the architecture of the current JVM.
+ * 
+ * Important: The os.arch System Property returns the architecture used by 
the JVM
+ * not of the operating system.
+ * 
+ */
+public class ArchUtils {
+
+private static Map map;
+
+static {
+map = new HashMap<>();
+init();
+}
+
+private static final void init() {
+init_X86_32Bit();
+init_X86_64Bit();
+init_IA64_32Bit();
+init_IA64_64Bit();
+init_PPC_32Bit();
+init_PPC_64Bit();
+}
+
+/**
+ * Adding x86 32 bit {@link Processor}'s to the map
+ */
+private static final void init_X86_32Bit() {
+Processor processor = new Processor(ProcessorArch.BIT_32, 
ProcessorType.X86);
+addProcessors(processor, "x86", "i386", "i486", "i586", "i686", 
"pentium");
+}
+
+/**
+ * Adding x86 64 bit {@link Processor}'s to the map
+ */
+private static final void init_X86_64Bit() {
+Processor processor = new Processor(ProcessorArch.BIT_64, 
ProcessorType.X86);
+addProcessors(processor, "x86_64", "amd64", "em64t", "universal");
+}
+
+/**
+ * Adding ia64 32 bit {@link Processor}'s to the map
+ */
+private static final void init_IA64_32Bit() {
+Processor processor = new Processor(ProcessorArch.BIT_32, 
ProcessorType.IA_64);
+addProcessors(processor, "ia64_32", "ia64n");
+}
+
+/**
+ * Adding ia64 64 bit {@link Processor}'s to the map
+ */
+private static final void init_IA64_64Bit() {
+Processor processor = new Processor(ProcessorArch.BIT_64, 
ProcessorType.IA_64);
+addProcessors(processor, "ia64", "ia64w");
+}
+
+/**
+ * Adding PPC 32 bit {@link Processor}'s to the map
+ */
+private static final void init_PPC_32Bit() {
+Processor processor = new Processor(ProcessorArch.BIT_32, 
ProcessorType.PPC);
+addProcessors(processor, "ppc", "power", "powerpc", "power_pc", 
"power_rs");
+}
+
+/**
+ * Adding PPC 64 bit {@link Processor}'s to the map
+ */
+private static final void init_PPC_64Bit() {
+Processor processor = new Processor(ProcessorArch.BIT_64, 
ProcessorType.PPC);
+addProcessors(processor, "ppc64", "power64", "powerpc64", 
"power_pc64", "power_rs64");
+}
+
+/**
+ * Adds the given {@link Processor} whith the given key {@link String} 
to the map.
+ *
+ * @param key The key as {@link String}.
+ * @param processor The {@link Processor} to add.
+ * @throws UnsupportedOperationException When key already exists in 
map.
+ */
+private static final void addProcessor(String key, Processor 
processor) throws UnsupportedOperationException {
+if (!map.containsKey(key)) {
+map.put(key, processor);
+} else {
+String msg = "Key " + key + " already exists in processor map";
+throw new UnsupportedOperationException(msg);
--- End diff --

IllegalStateException might be better here


---
If your project is set up for it, you can reply to this email and have

[jira] [Updated] (VFS-620) FileObject.moveTo(FileObject) API doesn't work well for a Linux FTP

2017-03-15 Thread Shon Vella (JIRA) 

 [ 
https://issues.apache.org/jira/browse/VFS-620?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
 ]

Shon Vella updated VFS-620:
---
Attachment: VFS-620c.patch

Sorry - I guess that what I get for trying to copy and paste the changes into 
the existing patch instead of doing a new diff from the sources that are 
working for me. Updated patch uploaded.



> FileObject.moveTo(FileObject) API doesn't work well for a Linux FTP
> ---
>
> Key: VFS-620
> URL: https://issues.apache.org/jira/browse/VFS-620
> Project: Commons VFS
>  Issue Type: Bug
>Affects Versions: 2.1
> Environment: ubuntu vsftpd
>Reporter: stevezhuang
> Attachments: VFS-620c.patch
>
>
> FileObject.moveTo(FileObject) API doesn't work well for a Linux FTP, 
> especially for setting a user directory as its root directory case,
> For example, for a ubuntu vsftpd, which is having "/home/user1" as its root 
> directory, when renaming "/test/test.txt" to "/test1/test1.txt", it will 
> throw an exception.
> In this case, it should consider the workingDirectory(would be "/home/user1") 
> together and append it to the from/to path to make the API work.
> Sample codes,
> FileObject fileObject = null;
> FileObject toFileObject = null;
> try {
> StandardFileSystemManager fsManager = new 
> StandardFileSystemManager();
> fsManager.init();
> FileSystemOptions fsOpts = new FileSystemOptions();
> FtpFileSystemConfigBuilder.getInstance().setPassiveMode(fsOpts, 
> true);
> FtpFileSystemConfigBuilder.getInstance().setUserDirIsRoot(fsOpts, 
> true);
> UserAuthenticator auth = new StaticUserAuthenticator(null, 
> "", "");
> 
> DefaultFileSystemConfigBuilder.getInstance().setUserAuthenticator(fsOpts, 
> auth);
> fileObject = fsManager.resolveFile("ftp:// address>/test/test.txt", fsOpts);
> System.out.println("File exists:" + fileObject.exists());
> toFileObject = fsManager.resolveFile("ftp:// address>/test1/test1.txt", fsOpts);
> System.out.println("File exists:" + toFileObject.exists());
> if (!toFileObject.exists()) {
> toFileObject.createFile();
> }
> fileObject.moveTo(toFileObject);
> } catch (FileSystemException ex) {
> ex.printStackTrace();
> } finally {
> if (fileObject != null) {
> try {
> fileObject.close();
> } catch (FileSystemException ex) {
> }
> }
> if (toFileObject != null) {
> try {
> toFileObject.close();
> } catch (FileSystemException ex) {
> }
> }
> }
> And the output,
> File exists:true
> File exists:false
> org.apache.commons.vfs2.FileSystemException: Could not rename 
> "ftp:///test/test.txt" to "ftp:// address>/test1/test1.txt".
>   at 
> org.apache.commons.vfs2.provider.AbstractFileObject.moveTo(AbstractFileObject.java:1902)
>   at TestFTP.main(TestFTP.java:59)
> Caused by: org.apache.commons.vfs2.FileSystemException: Could not rename FTP 
> file "ftp:///test/test.txt" to "ftp:// address>/test1/test1.txt".
>   at 
> org.apache.commons.vfs2.provider.ftp.FtpFileObject.doRename(FtpFileObject.java:524)
>   at 
> org.apache.commons.vfs2.provider.AbstractFileObject.moveTo(AbstractFileObject.java:1887)



--
This message was sent by Atlassian JIRA
(v6.3.15#6346)

[jira] [Updated] (VFS-620) FileObject.moveTo(FileObject) API doesn't work well for a Linux FTP

2017-03-15 Thread Shon Vella (JIRA) 

 [ 
https://issues.apache.org/jira/browse/VFS-620?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
 ]

Shon Vella updated VFS-620:
---
Attachment: (was: VFS-620.patch)

> FileObject.moveTo(FileObject) API doesn't work well for a Linux FTP
> ---
>
> Key: VFS-620
> URL: https://issues.apache.org/jira/browse/VFS-620
> Project: Commons VFS
>  Issue Type: Bug
>Affects Versions: 2.1
> Environment: ubuntu vsftpd
>Reporter: stevezhuang
>
> FileObject.moveTo(FileObject) API doesn't work well for a Linux FTP, 
> especially for setting a user directory as its root directory case,
> For example, for a ubuntu vsftpd, which is having "/home/user1" as its root 
> directory, when renaming "/test/test.txt" to "/test1/test1.txt", it will 
> throw an exception.
> In this case, it should consider the workingDirectory(would be "/home/user1") 
> together and append it to the from/to path to make the API work.
> Sample codes,
> FileObject fileObject = null;
> FileObject toFileObject = null;
> try {
> StandardFileSystemManager fsManager = new 
> StandardFileSystemManager();
> fsManager.init();
> FileSystemOptions fsOpts = new FileSystemOptions();
> FtpFileSystemConfigBuilder.getInstance().setPassiveMode(fsOpts, 
> true);
> FtpFileSystemConfigBuilder.getInstance().setUserDirIsRoot(fsOpts, 
> true);
> UserAuthenticator auth = new StaticUserAuthenticator(null, 
> "", "");
> 
> DefaultFileSystemConfigBuilder.getInstance().setUserAuthenticator(fsOpts, 
> auth);
> fileObject = fsManager.resolveFile("ftp:// address>/test/test.txt", fsOpts);
> System.out.println("File exists:" + fileObject.exists());
> toFileObject = fsManager.resolveFile("ftp:// address>/test1/test1.txt", fsOpts);
> System.out.println("File exists:" + toFileObject.exists());
> if (!toFileObject.exists()) {
> toFileObject.createFile();
> }
> fileObject.moveTo(toFileObject);
> } catch (FileSystemException ex) {
> ex.printStackTrace();
> } finally {
> if (fileObject != null) {
> try {
> fileObject.close();
> } catch (FileSystemException ex) {
> }
> }
> if (toFileObject != null) {
> try {
> toFileObject.close();
> } catch (FileSystemException ex) {
> }
> }
> }
> And the output,
> File exists:true
> File exists:false
> org.apache.commons.vfs2.FileSystemException: Could not rename 
> "ftp:///test/test.txt" to "ftp:// address>/test1/test1.txt".
>   at 
> org.apache.commons.vfs2.provider.AbstractFileObject.moveTo(AbstractFileObject.java:1902)
>   at TestFTP.main(TestFTP.java:59)
> Caused by: org.apache.commons.vfs2.FileSystemException: Could not rename FTP 
> file "ftp:///test/test.txt" to "ftp:// address>/test1/test1.txt".
>   at 
> org.apache.commons.vfs2.provider.ftp.FtpFileObject.doRename(FtpFileObject.java:524)
>   at 
> org.apache.commons.vfs2.provider.AbstractFileObject.moveTo(AbstractFileObject.java:1887)



--
This message was sent by Atlassian JIRA
(v6.3.15#6346)

[jira] [Commented] (VFS-620) FileObject.moveTo(FileObject) API doesn't work well for a Linux FTP

2017-03-15 Thread Gary Gregory (JIRA) 

[ 
https://issues.apache.org/jira/browse/VFS-620?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=15926789#comment-15926789
 ] 

Gary Gregory commented on VFS-620:
--

Hi Shon,

The patch does not compile. For example:

{noformat}
+protected String getFtpRootDir()
+{
+return return new File(getTestDirectory(), "homeDirIsRoot").getPath();
+}
{noformat}

> FileObject.moveTo(FileObject) API doesn't work well for a Linux FTP
> ---
>
> Key: VFS-620
> URL: https://issues.apache.org/jira/browse/VFS-620
> Project: Commons VFS
>  Issue Type: Bug
>Affects Versions: 2.1
> Environment: ubuntu vsftpd
>Reporter: stevezhuang
> Attachments: VFS-620.patch
>
>
> FileObject.moveTo(FileObject) API doesn't work well for a Linux FTP, 
> especially for setting a user directory as its root directory case,
> For example, for a ubuntu vsftpd, which is having "/home/user1" as its root 
> directory, when renaming "/test/test.txt" to "/test1/test1.txt", it will 
> throw an exception.
> In this case, it should consider the workingDirectory(would be "/home/user1") 
> together and append it to the from/to path to make the API work.
> Sample codes,
> FileObject fileObject = null;
> FileObject toFileObject = null;
> try {
> StandardFileSystemManager fsManager = new 
> StandardFileSystemManager();
> fsManager.init();
> FileSystemOptions fsOpts = new FileSystemOptions();
> FtpFileSystemConfigBuilder.getInstance().setPassiveMode(fsOpts, 
> true);
> FtpFileSystemConfigBuilder.getInstance().setUserDirIsRoot(fsOpts, 
> true);
> UserAuthenticator auth = new StaticUserAuthenticator(null, 
> "", "");
> 
> DefaultFileSystemConfigBuilder.getInstance().setUserAuthenticator(fsOpts, 
> auth);
> fileObject = fsManager.resolveFile("ftp:// address>/test/test.txt", fsOpts);
> System.out.println("File exists:" + fileObject.exists());
> toFileObject = fsManager.resolveFile("ftp:// address>/test1/test1.txt", fsOpts);
> System.out.println("File exists:" + toFileObject.exists());
> if (!toFileObject.exists()) {
> toFileObject.createFile();
> }
> fileObject.moveTo(toFileObject);
> } catch (FileSystemException ex) {
> ex.printStackTrace();
> } finally {
> if (fileObject != null) {
> try {
> fileObject.close();
> } catch (FileSystemException ex) {
> }
> }
> if (toFileObject != null) {
> try {
> toFileObject.close();
> } catch (FileSystemException ex) {
> }
> }
> }
> And the output,
> File exists:true
> File exists:false
> org.apache.commons.vfs2.FileSystemException: Could not rename 
> "ftp:///test/test.txt" to "ftp:// address>/test1/test1.txt".
>   at 
> org.apache.commons.vfs2.provider.AbstractFileObject.moveTo(AbstractFileObject.java:1902)
>   at TestFTP.main(TestFTP.java:59)
> Caused by: org.apache.commons.vfs2.FileSystemException: Could not rename FTP 
> file "ftp:///test/test.txt" to "ftp:// address>/test1/test1.txt".
>   at 
> org.apache.commons.vfs2.provider.ftp.FtpFileObject.doRename(FtpFileObject.java:524)
>   at 
> org.apache.commons.vfs2.provider.AbstractFileObject.moveTo(AbstractFileObject.java:1887)



--
This message was sent by Atlassian JIRA
(v6.3.15#6346)

[jira] [Commented] (NUMBERS-14) call to hashCode() in Complex

2017-03-15 Thread Gilles (JIRA) 

[ 
https://issues.apache.org/jira/browse/NUMBERS-14?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=15926538#comment-15926538
 ] 

Gilles commented on NUMBERS-14:
---

In {{Precision}}?

This is the method in CM:
{code}
public int hashCode() {
if (isNaN) {
return 7;
}
return 37 * (17 * MathUtils.hash(imaginary) +
MathUtils.hash(real));
}
{code}

For the moment, I'd just replace "MathUtils" with a private method designed as 
in 
[Double|https://docs.oracle.com/javase/7/docs/api/java/lang/Double.html#hashCode%28%29]:
{code}
private int hash(double d) {
  final long v = Double.doubleToLongBits(d);
  return (int)(v^(v>>>32));
}
{code}


> call to hashCode() in Complex
> -
>
> Key: NUMBERS-14
> URL: https://issues.apache.org/jira/browse/NUMBERS-14
> Project: Commons Numbers
>  Issue Type: Improvement
>Affects Versions: 1.0
>Reporter: Eric Barnhill
>Priority: Trivial
>  Labels: easyfix
>
> There is a call in Complex() to hashCode(). This calls a method 
> Precision.hash() . Looks like Precision.hash() is gone. I want to confirm 
> that this method is now gone from commons-numbers Precision() and 
> consequently I should remove this method.



--
This message was sent by Atlassian JIRA
(v6.3.15#6346)

[jira] [Created] (VFS-630) Sftp code assumes that exec channels are available and *nix server

2017-03-15 Thread Will Wood (JIRA) 
Will Wood created VFS-630:
-

 Summary: Sftp code assumes that exec channels are available and 
*nix server
 Key: VFS-630
 URL: https://issues.apache.org/jira/browse/VFS-630
 Project: Commons VFS
  Issue Type: Bug
Affects Versions: 2.1
 Environment: Any client running VFS 2.1/JSch 1.51 and later using 
remote sftp server that's locked down or not *nix based.
Reporter: Will Wood
Priority: Minor


In working with VFS using SFTP there's an assumption in the code that creates a 
problem if the remote server is locked down or it's not *nix based.  I hit this 
when working with a server that had exec commands disabled and attempting to do 
a moveTo command on a remote file object renaming it to the same server as a 
remote file object.  At one point the VFS code attempts to execute an "id -G" 
command on a JSch "exec" channel. Since the remote server disallows the exec 
command the subsequent read from the input stream blocks until the O/S default 
socket timeout occurs, it basically hangs.
I tested this same scenario against a Linux server, it worked fine.  I also 
tested a Windows server which doesn't have an id command, it failed.

Since JSch deals with this natively, I would recommend getting rid of the exec 
commands altogether and letting the client deal with those issues outside of 
the framework, i.e., moveTo in this case doesn't need to worry about 
permissions but rather throws the underlying exceptions from JSch.




--
This message was sent by Atlassian JIRA
(v6.3.15#6346)

[jira] [Created] (EMAIL-168) Content-Description should not be added if it is not provided

2017-03-15 Thread Sebb (JIRA) 
Sebb created EMAIL-168:
--

 Summary: Content-Description should not be added if it is not 
provided
 Key: EMAIL-168
 URL: https://issues.apache.org/jira/browse/EMAIL-168
 Project: Commons Email
  Issue Type: Bug
Reporter: Sebb


At present the Content-Description header is added to attachment parts unless 
it is null.

Since the default value is an empty string, this means that an empty C-D: 
header is added by default.

Changing the default field value to null would prevent the header from being 
added unless the user calls EmailAttachment#setDescription(String desc), 

However there seems little point in adding the header if it is the empty 
string, so a better solution might be to skip it if the value is null or the 
empty string.



--
This message was sent by Atlassian JIRA
(v6.3.15#6346)

[jira] [Created] (NUMBERS-14) call to hashCode() in Complex

2017-03-15 Thread Eric Barnhill (JIRA) 
Eric Barnhill created NUMBERS-14:


 Summary: call to hashCode() in Complex
 Key: NUMBERS-14
 URL: https://issues.apache.org/jira/browse/NUMBERS-14
 Project: Commons Numbers
  Issue Type: Improvement
Affects Versions: 1.0
Reporter: Eric Barnhill
Priority: Trivial


There is a call in Complex() to hashCode(). This calls a method 
Precision.hash() . Looks like Precision.hash() is gone. I want to confirm that 
this method is now gone from commons-numbers Precision() and consequently I 
should remove this method.



--
This message was sent by Atlassian JIRA
(v6.3.15#6346)

[jira] [Commented] (LANG-1300) Clarify or improve behaviour of int-based methods in StringUtils

2017-03-15 Thread ASF GitHub Bot (JIRA) 

[ 
https://issues.apache.org/jira/browse/LANG-1300?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=15926350#comment-15926350
 ] 

ASF GitHub Bot commented on LANG-1300:
--

Github user coveralls commented on the issue:

https://github.com/apache/commons-lang/pull/258
  

[![Coverage 
Status](https://coveralls.io/builds/10607361/badge)](https://coveralls.io/builds/10607361)

Coverage increased (+0.05%) to 94.576% when pulling 
**0e1b328e5697196d944b9e85356020743066ff3b on chtompki:LANG-1300** into 
**6700d58fd6538f531d282b98e4d31fadd35e87da on apache:master**.



> Clarify or improve behaviour of int-based methods in StringUtils
> 
>
> Key: LANG-1300
> URL: https://issues.apache.org/jira/browse/LANG-1300
> Project: Commons Lang
>  Issue Type: Improvement
>  Components: lang.*
>Affects Versions: 3.5
>Reporter: Duncan Jones
>Priority: Minor
> Fix For: Discussion
>
>
> The following methods use an {{int}} to represent a search character:
> {code:java}
> boolean contains(final CharSequence seq, final int searchChar)
> int indexOf(final CharSequence seq, final int searchChar)
> int indexOf(final CharSequence seq, final int searchChar, final int startPos)
> int lastIndexOf(final CharSequence seq, final int searchChar)
> int lastIndexOf(final CharSequence seq, final int searchChar, final int 
> startPos)
> {code}
> When I see an {{int}} representing a character, I tend to assume the method 
> can handle supplementary characters. However, the current behaviour of these 
> methods depends upon whether the {{CharSequence}} is a {{String}} or not.
> {code:java}
> StringBuilder builder = new StringBuilder();
> builder.appendCodePoint(0x2070E);
> System.out.println(StringUtils.lastIndexOf(builder, 0x2070E)); // -1
> System.out.println(StringUtils.lastIndexOf(builder.toString(), 0x2070E)); // 0
> {code}
> The Javadoc for these methods are ambiguous on this point, stating:
> {quote}
> This method uses {{String.lastIndexOf(int)}} if possible.
> {quote}
> I think we should consider updating the {{CharSequenceUtils}} methods used by 
> this class to convert all {{CharSequence}} parameters to strings, enabling 
> full code point support. The docs could be updated to make this crystal clear.
> There is a question of whether this breaks backwards compatibility.



--
This message was sent by Atlassian JIRA
(v6.3.15#6346)

[GitHub] commons-lang issue #258: LANG-1300: Added documentation

2017-03-15 Thread coveralls 
Github user coveralls commented on the issue:

https://github.com/apache/commons-lang/pull/258
  

[![Coverage 
Status](https://coveralls.io/builds/10607361/badge)](https://coveralls.io/builds/10607361)

Coverage increased (+0.05%) to 94.576% when pulling 
**0e1b328e5697196d944b9e85356020743066ff3b on chtompki:LANG-1300** into 
**6700d58fd6538f531d282b98e4d31fadd35e87da on apache:master**.



---
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] [Commented] (CLI-271) CommandLine.getXXX and CommandLine.hasXXX should accept an Option as a parameter

2017-03-15 Thread JIRA 

[ 
https://issues.apache.org/jira/browse/CLI-271?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=15926292#comment-15926292
 ] 

Christoph Läubrich commented on CLI-271:


Opened https://github.com/apache/commons-cli/pull/9

> CommandLine.getXXX and CommandLine.hasXXX should accept an Option as a 
> parameter
> 
>
> Key: CLI-271
> URL: https://issues.apache.org/jira/browse/CLI-271
> Project: Commons CLI
>  Issue Type: Improvement
>  Components: CLI-1.x
>Affects Versions: 1.4
>Reporter: Christoph Läubrich
>
> Currently there is some searching and String matching to find a matching 
> option for the hasXXX and getXXX it would be nice to pass in an Option 
> instance directly, this would also allow further improvements (e.g. infer the 
> type of an option), prevents exhaustive search for matching option as well as 
> type-safety.



--
This message was sent by Atlassian JIRA
(v6.3.15#6346)

[jira] [Commented] (CLI-271) CommandLine.getXXX and CommandLine.hasXXX should accept an Option as a parameter

2017-03-15 Thread ASF GitHub Bot (JIRA) 

[ 
https://issues.apache.org/jira/browse/CLI-271?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=15926290#comment-15926290
 ] 

ASF GitHub Bot commented on CLI-271:


GitHub user laeubi opened a pull request:

https://github.com/apache/commons-cli/pull/9

Fix for CLI-271

Add the posibility to use Options as a parameter for fetching values from 
the CommandLine.

You can merge this pull request into a Git repository by running:

$ git pull https://github.com/laeubi/commons-cli CLI-271

Alternatively you can review and apply these changes as the patch at:

https://github.com/apache/commons-cli/pull/9.patch

To close this pull request, make a commit to your master/trunk branch
with (at least) the following in the commit message:

This closes #9


commit e1f3164cba66b9ec83dfca320ea549d0f666fae5
Author: laeubi 
Date:   2017-03-15T14:44:35Z

Fix for CLI-271
Add some Tests for coverage




> CommandLine.getXXX and CommandLine.hasXXX should accept an Option as a 
> parameter
> 
>
> Key: CLI-271
> URL: https://issues.apache.org/jira/browse/CLI-271
> Project: Commons CLI
>  Issue Type: Improvement
>  Components: CLI-1.x
>Affects Versions: 1.4
>Reporter: Christoph Läubrich
>
> Currently there is some searching and String matching to find a matching 
> option for the hasXXX and getXXX it would be nice to pass in an Option 
> instance directly, this would also allow further improvements (e.g. infer the 
> type of an option), prevents exhaustive search for matching option as well as 
> type-safety.



--
This message was sent by Atlassian JIRA
(v6.3.15#6346)

[jira] [Commented] (JXPATH-190) Make BeanUtils dependency optional in BasicTypeConverter

2017-03-15 Thread Tobias Gruetzmacher (JIRA) 

[ 
https://issues.apache.org/jira/browse/JXPATH-190?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=15926203#comment-15926203
 ] 

Tobias Gruetzmacher commented on JXPATH-190:


Pull request: https://github.com/apache/commons-jxpath/pull/13

> Make BeanUtils dependency optional in BasicTypeConverter
> 
>
> Key: JXPATH-190
> URL: https://issues.apache.org/jira/browse/JXPATH-190
> Project: Commons JXPath
>  Issue Type: Improvement
>Affects Versions: 1.3
>Reporter: Tobias Gruetzmacher
>
> When using BasicTypeConverter.canConvert or BasicTypeConverter.convert, if 
> the method can't find a "simple" solution, it tries to fall back to 
> org.apache.commons.beanutils.ConvertUtils.lookup - since commons-beanutils is 
> an optional dependency, this class might not be available, so you end up with 
> a nasty  java.lang.NoClassDefFoundError...
> My proposal would be to make this call optional too, so users of JXPath don't 
> need to depend on commons-beanutils.



--
This message was sent by Atlassian JIRA
(v6.3.15#6346)

[jira] [Created] (JXPATH-190) Make BeanUtils dependency optional in BasicTypeConverter

2017-03-15 Thread Tobias Gruetzmacher (JIRA) 
Tobias Gruetzmacher created JXPATH-190:
--

 Summary: Make BeanUtils dependency optional in BasicTypeConverter
 Key: JXPATH-190
 URL: https://issues.apache.org/jira/browse/JXPATH-190
 Project: Commons JXPath
  Issue Type: Improvement
Affects Versions: 1.3
Reporter: Tobias Gruetzmacher


When using BasicTypeConverter.canConvert or BasicTypeConverter.convert, if the 
method can't find a "simple" solution, it tries to fall back to 
org.apache.commons.beanutils.ConvertUtils.lookup - since commons-beanutils is 
an optional dependency, this class might not be available, so you end up with a 
nasty  java.lang.NoClassDefFoundError...

My proposal would be to make this call optional too, so users of JXPath don't 
need to depend on commons-beanutils.



--
This message was sent by Atlassian JIRA
(v6.3.15#6346)

[jira] [Commented] (LANG-1300) Clarify or improve behaviour of int-based methods in StringUtils

2017-03-15 Thread ASF GitHub Bot (JIRA) 

[ 
https://issues.apache.org/jira/browse/LANG-1300?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=15926088#comment-15926088
 ] 

ASF GitHub Bot commented on LANG-1300:
--

GitHub user chtompki opened a pull request:

https://github.com/apache/commons-lang/pull/258

LANG-1300: Added documentation

@MarkDacek - let me know what you think.

This extends #251.

You can merge this pull request into a Git repository by running:

$ git pull https://github.com/chtompki/commons-lang LANG-1300

Alternatively you can review and apply these changes as the patch at:

https://github.com/apache/commons-lang/pull/258.patch

To close this pull request, make a commit to your master/trunk branch
with (at least) the following in the commit message:

This closes #258






> Clarify or improve behaviour of int-based methods in StringUtils
> 
>
> Key: LANG-1300
> URL: https://issues.apache.org/jira/browse/LANG-1300
> Project: Commons Lang
>  Issue Type: Improvement
>  Components: lang.*
>Affects Versions: 3.5
>Reporter: Duncan Jones
>Priority: Minor
> Fix For: Discussion
>
>
> The following methods use an {{int}} to represent a search character:
> {code:java}
> boolean contains(final CharSequence seq, final int searchChar)
> int indexOf(final CharSequence seq, final int searchChar)
> int indexOf(final CharSequence seq, final int searchChar, final int startPos)
> int lastIndexOf(final CharSequence seq, final int searchChar)
> int lastIndexOf(final CharSequence seq, final int searchChar, final int 
> startPos)
> {code}
> When I see an {{int}} representing a character, I tend to assume the method 
> can handle supplementary characters. However, the current behaviour of these 
> methods depends upon whether the {{CharSequence}} is a {{String}} or not.
> {code:java}
> StringBuilder builder = new StringBuilder();
> builder.appendCodePoint(0x2070E);
> System.out.println(StringUtils.lastIndexOf(builder, 0x2070E)); // -1
> System.out.println(StringUtils.lastIndexOf(builder.toString(), 0x2070E)); // 0
> {code}
> The Javadoc for these methods are ambiguous on this point, stating:
> {quote}
> This method uses {{String.lastIndexOf(int)}} if possible.
> {quote}
> I think we should consider updating the {{CharSequenceUtils}} methods used by 
> this class to convert all {{CharSequence}} parameters to strings, enabling 
> full code point support. The docs could be updated to make this crystal clear.
> There is a question of whether this breaks backwards compatibility.



--
This message was sent by Atlassian JIRA
(v6.3.15#6346)

[GitHub] commons-lang pull request #258: LANG-1300: Added documentation

2017-03-15 Thread chtompki 
GitHub user chtompki opened a pull request:

https://github.com/apache/commons-lang/pull/258

LANG-1300: Added documentation

@MarkDacek - let me know what you think.

This extends #251.

You can merge this pull request into a Git repository by running:

$ git pull https://github.com/chtompki/commons-lang LANG-1300

Alternatively you can review and apply these changes as the patch at:

https://github.com/apache/commons-lang/pull/258.patch

To close this pull request, make a commit to your master/trunk branch
with (at least) the following in the commit message:

This closes #258






---
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] [Commented] (LANG-1300) Clarify or improve behaviour of int-based methods in StringUtils

2017-03-15 Thread ASF GitHub Bot (JIRA) 

[ 
https://issues.apache.org/jira/browse/LANG-1300?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=15926061#comment-15926061
 ] 

ASF GitHub Bot commented on LANG-1300:
--

Github user chtompki commented on the issue:

https://github.com/apache/commons-lang/pull/251
  
I'm going to make some documentation changes here. I'll keep you apprised 
as I make them.


> Clarify or improve behaviour of int-based methods in StringUtils
> 
>
> Key: LANG-1300
> URL: https://issues.apache.org/jira/browse/LANG-1300
> Project: Commons Lang
>  Issue Type: Improvement
>  Components: lang.*
>Affects Versions: 3.5
>Reporter: Duncan Jones
>Priority: Minor
> Fix For: Discussion
>
>
> The following methods use an {{int}} to represent a search character:
> {code:java}
> boolean contains(final CharSequence seq, final int searchChar)
> int indexOf(final CharSequence seq, final int searchChar)
> int indexOf(final CharSequence seq, final int searchChar, final int startPos)
> int lastIndexOf(final CharSequence seq, final int searchChar)
> int lastIndexOf(final CharSequence seq, final int searchChar, final int 
> startPos)
> {code}
> When I see an {{int}} representing a character, I tend to assume the method 
> can handle supplementary characters. However, the current behaviour of these 
> methods depends upon whether the {{CharSequence}} is a {{String}} or not.
> {code:java}
> StringBuilder builder = new StringBuilder();
> builder.appendCodePoint(0x2070E);
> System.out.println(StringUtils.lastIndexOf(builder, 0x2070E)); // -1
> System.out.println(StringUtils.lastIndexOf(builder.toString(), 0x2070E)); // 0
> {code}
> The Javadoc for these methods are ambiguous on this point, stating:
> {quote}
> This method uses {{String.lastIndexOf(int)}} if possible.
> {quote}
> I think we should consider updating the {{CharSequenceUtils}} methods used by 
> this class to convert all {{CharSequence}} parameters to strings, enabling 
> full code point support. The docs could be updated to make this crystal clear.
> There is a question of whether this breaks backwards compatibility.



--
This message was sent by Atlassian JIRA
(v6.3.15#6346)

[GitHub] commons-lang issue #251: LANG-1300: Change CharSequenceUtils to support supp...

2017-03-15 Thread chtompki 
Github user chtompki commented on the issue:

https://github.com/apache/commons-lang/pull/251
  
I'm going to make some documentation changes here. I'll keep you apprised 
as I make them.


---
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] [Updated] (EMAIL-167) DataSourceClassPathResolver doesn't close InputStream when resolving resources

2017-03-15 Thread Lucian Burja (JIRA) 

 [ 
https://issues.apache.org/jira/browse/EMAIL-167?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
 ]

Lucian Burja updated EMAIL-167:
---
Attachment: EMAIL-167-close-input-stream.patch

Patch that closes the input stream in a try..finally block.

> DataSourceClassPathResolver doesn't close InputStream when resolving resources
> --
>
> Key: EMAIL-167
> URL: https://issues.apache.org/jira/browse/EMAIL-167
> Project: Commons Email
>  Issue Type: Bug
>Affects Versions: 1.4
>Reporter: Lucian Burja
> Attachments: EMAIL-167-close-input-stream.patch
>
>
> DataSourceClassPathResolver opens an InputStream (via 
> .class.getResourceAsStream) to read a resource into a ByteArrayDataSource, 
> but never closes it:
> {code}
> public DataSource resolve(final String resourceLocation, final boolean 
> isLenient) throws IOException
> {
> ...
> final InputStream is = 
> DataSourceClassPathResolver.class.getResourceAsStream(resourceName);
> if (is != null)
> {
> final ByteArrayDataSource ds = new 
> ByteArrayDataSource(is, mimeType);
> // EMAIL-125: set the name of the DataSource to the 
> normalized resource URL
> // similar to other DataSource implementations, e.g. 
> FileDataSource, URLDataSource
> 
> ds.setName(DataSourceClassPathResolver.class.getResource(resourceName).toString());
> result = ds;
> }
> {code}
> The 'is' variable above should be closed in a try ... finally



--
This message was sent by Atlassian JIRA
(v6.3.15#6346)

[jira] [Commented] (JEXL-222) The ability to declare indexed property getter/setter in customised JexlArithmetic implementation

2017-03-15 Thread Dmitri Blinov (JIRA) 

[ 
https://issues.apache.org/jira/browse/JEXL-222?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=15925764#comment-15925764
 ] 

Dmitri Blinov commented on JEXL-222:


It has worked for me with the following code: 
{code}
...public Object propertySet(IndexedType.IndexedContainer map, String 
key, Integer value) {
if 
(PropertyContainer.class.isAssignableFrom(map.getContainerClass())
&& map.getContainerName().equals("property")) {
try {
map.set(key, value.toString());
} catch (Exception xany) {
throw new JexlException.Operator(null, 
map.getContainerClass() + "." + key, xany);
}
return null;
}
return JexlEngine.TRY_FAILED;
}
...
{code}

Great work, thanks!

> The ability to declare indexed property getter/setter in customised 
> JexlArithmetic implementation
> -
>
> Key: JEXL-222
> URL: https://issues.apache.org/jira/browse/JEXL-222
> Project: Commons JEXL
>  Issue Type: Improvement
>Affects Versions: 3.0
>Reporter: Dmitri Blinov
>Assignee: Henri Biestro
>Priority: Minor
> Fix For: 3.1
>
>
> At the moment we have the ability to declare a specific getter/setter method 
> in customized JexlArithmetic class that will be used by Jexl engine when 
> engine tries to get access to a property of some object. This is great 
> extension point of the Jexl but I have come to a situation where I need the 
> same technics to be applied to indexed properties. For example I'm scripting 
> org.w3c.dom.Element object by setting its attributes via its 
> {code}Element.setAttribute(java.lang.String name, java.lang.String value) 
> {code} method. In Jexl I use standard indexed property access syntax like the 
> following: {code} node.attribute.id = "12345"; {code} The problem lies with 
> the last argument of the setAttribute method which is of String class. And 
> for Jexl standard indexed property setter to work I should always remember 
> that in script I need to cast specified property value to a string, which is 
> error-prone and lacks, in my understanding, scripting easiness. I see the 
> solution as to introduce custom indexed property setter in more generalized 
> form, accepting Object type as a value so it could cast a value to String 
> before calling {{Element.setAttribute}}



--
This message was sent by Atlassian JIRA
(v6.3.15#6346)

[jira] [Updated] (JEXL-217) Interpreter.getAttribute() raises exception in non-strict mode when cached property resolver is used

2017-03-15 Thread Henri Biestro (JIRA) 

 [ 
https://issues.apache.org/jira/browse/JEXL-217?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
 ]

Henri Biestro updated JEXL-217:
---
Fix Version/s: 3.1

> Interpreter.getAttribute() raises exception in non-strict mode when cached 
> property resolver is used
> 
>
> Key: JEXL-217
> URL: https://issues.apache.org/jira/browse/JEXL-217
> Project: Commons JEXL
>  Issue Type: Bug
>Affects Versions: 3.0
>Reporter: Dmitri Blinov
>Assignee: Henri Biestro
> Fix For: 3.1
>
>
> I'm chasing strange bug where regardless of the {{JexlContext}} operating in 
> non-strict mode the {{ArrayIndexOutOfBoundsException}} is thrown in the 
> script like this
> {code}
> entity = args[0]; @lenient {copy = args[1]; xwsp = args[2]}
> {code}
> here is the stack trace
> {quote}
> Caused by: java.lang.ArrayIndexOutOfBoundsException
>   at java.lang.reflect.Array.get(Native Method)
>   at 
> org.apache.commons.jexl3.internal.introspection.ListGetExecutor.tryInvoke(ListGetExecutor.java:88)
>  
>   at 
> org.apache.commons.jexl3.internal.Interpreter.getAttribute(Interpreter.java:1700)
>  
>   at 
> org.apache.commons.jexl3.internal.Interpreter.visit(Interpreter.java:945) 
>   at 
> org.apache.commons.jexl3.parser.ASTArrayAccess.jjtAccept(ASTArrayAccess.java:18)
>  
>   at 
> org.apache.commons.jexl3.internal.Interpreter.visit(Interpreter.java:1013) 
>   at 
> org.apache.commons.jexl3.parser.ASTReference.jjtAccept(ASTReference.java:18) 
>   at 
> org.apache.commons.jexl3.internal.Interpreter.executeAssign(Interpreter.java:1119)
>  
>   at 
> org.apache.commons.jexl3.internal.Interpreter.visit(Interpreter.java:1062) 
>   at 
> org.apache.commons.jexl3.parser.ASTAssignment.jjtAccept(ASTAssignment.java:18)
>  
>   at 
> org.apache.commons.jexl3.internal.Interpreter.visit(Interpreter.java:578) 
>   at org.apache.commons.jexl3.parser.ASTBlock.jjtAccept(ASTBlock.java:18) 
>   at 
> org.apache.commons.jexl3.internal.Interpreter.processAnnotation(Interpreter.java:1848)
>  
>   at 
> org.apache.commons.jexl3.internal.Interpreter$1.call(Interpreter.java:1856) 
> {quote}
> Unfortunately I haven't managed to create and provide reproducible test case, 
> but from looking into the code I think the problem fires when the Interpreter 
> tries to call cached method {{ListGetExecutor.tryInvoke()}} but does not 
> catch subsequent exception.  
> I rewrote the code as follows and the problem seemed to go away
> {code:title=Interpreter.java}
> ...
> Exception xcause = null;
> // attempt to reuse last executor cached in volatile JexlNode.value
> if (node != null && cache) {
> Object cached = node.jjtGetValue();
> if (cached instanceof JexlPropertyGet) {
> JexlPropertyGet vg = (JexlPropertyGet) cached;
> try {
>Object value = vg.tryInvoke(object, attribute);
>if (!vg.tryFailed(value)) {
>return value;
>}
> } catch (Exception xany) {
> xcause = xany;
> }
> }
> }
> if (xcause == null) {
>// resolve that property
>List resolvers = 
> uberspect.getResolvers(operator, object);
>JexlPropertyGet vg = uberspect.getPropertyGet(resolvers, object, 
> attribute);
>if (vg != null) {
>try {
>Object value = vg.invoke(object);
>// cache executor in volatile JexlNode.value
>if (node != null && cache && vg.isCacheable()) {
>node.jjtSetValue(vg);
>}
>return value;
>} catch (Exception xany) {
>xcause = xany;
>}
>}
> }
> ...
> {code}



--
This message was sent by Atlassian JIRA
(v6.3.15#6346)