[jira] [Commented] (NET-405) Support for IPv6 in SubnetUtils

2018-04-11 Thread Makoto Sakaguchi (JIRA) 

[ 
https://issues.apache.org/jira/browse/NET-405?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16434734#comment-16434734
 ] 

Makoto Sakaguchi commented on NET-405:
--

Hi [~BigPandaToo],

My pull request on Github has not been merged to the official repository yet.

I do not know when it will be available.

> Support for IPv6 in SubnetUtils
> ---
>
> Key: NET-405
> URL: https://issues.apache.org/jira/browse/NET-405
> Project: Commons Net
>  Issue Type: Improvement
>Reporter: Marc Lefrancois
>Priority: Major
>
> Currently, we cannot use org.apache.commons.net.util.SubnetUtils with IPv6 
> addresses. This class will become less and less useful as more internet 
> device are only assigned IPv6 addresses since all available IPv4 address 
> blocks have now been attributed. 
> http://en.wikipedia.org/wiki/IPv4_address_exhaustion



--
This message was sent by Atlassian JIRA
(v7.6.3#76005)

[jira] [Updated] (JEXL-258) JEXL unset method

2018-04-11 Thread Osy (JIRA) 

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

Osy updated JEXL-258:
-
Description: 
Currently we have a set method to put in context a new expresion variable.
  
*void org.apache.commons.jexl3.JexlContext.set(String arg0, Object arg1)*

 
 However, I have the need of clean some variables for each Iteration, so please 
analyze if is possible to add an unset method to do the opposite action to set 
method.
  

  was:
Currently we have a set method to put in context a new expresion variable.
 
*void 
[org|eclipse-javadoc:%E2%98%82=IceExpre/C:%5C/Users%5C/ossoto%5C/.m2%5C/repository%5C/org%5C/apache%5C/commons%5C/commons-jexl3%5C/3.1%5C/commons-jexl3-3.1.jar%3Corg].[apache|eclipse-javadoc:%E2%98%82=IceExpre/C:%5C/Users%5C/ossoto%5C/.m2%5C/repository%5C/org%5C/apache%5C/commons%5C/commons-jexl3%5C/3.1%5C/commons-jexl3-3.1.jar%3Corg.apache].[commons|eclipse-javadoc:%E2%98%82=IceExpre/C:%5C/Users%5C/ossoto%5C/.m2%5C/repository%5C/org%5C/apache%5C/commons%5C/commons-jexl3%5C/3.1%5C/commons-jexl3-3.1.jar%3Corg.apache.commons].[jexl3|eclipse-javadoc:%E2%98%82=IceExpre/C:%5C/Users%5C/ossoto%5C/.m2%5C/repository%5C/org%5C/apache%5C/commons%5C/commons-jexl3%5C/3.1%5C/commons-jexl3-3.1.jar%3Corg.apache.commons.jexl3].[JexlContext|eclipse-javadoc:%E2%98%82=IceExpre/C:%5C/Users%5C/ossoto%5C/.m2%5C/repository%5C/org%5C/apache%5C/commons%5C/commons-jexl3%5C/3.1%5C/commons-jexl3-3.1.jar%3Corg.apache.commons.jexl3(JexlContext.class%E2%98%83JexlContext].set([String|eclipse-javadoc:%E2%98%82=IceExpre/C:%5C/Users%5C/ossoto%5C/.m2%5C/repository%5C/org%5C/apache%5C/commons%5C/commons-jexl3%5C/3.1%5C/commons-jexl3-3.1.jar%3Corg.apache.commons.jexl3(JexlContext.class%E2%98%83JexlContext~set~Ljava.lang.String;~Ljava.lang.Object;%E2%98%82java.lang.String]
 arg0, 
[Object|eclipse-javadoc:%E2%98%82=IceExpre/C:%5C/Users%5C/ossoto%5C/.m2%5C/repository%5C/org%5C/apache%5C/commons%5C/commons-jexl3%5C/3.1%5C/commons-jexl3-3.1.jar%3Corg.apache.commons.jexl3(JexlContext.class%E2%98%83JexlContext~set~Ljava.lang.String;~Ljava.lang.Object;%E2%98%82java.lang.Object]
 arg1)*
 
However, I have the need of clean some variables for each Iteration, so please 
analyze if is possible to add an unset method to do the opposite action to set 
method.
 


> JEXL unset method
> -
>
> Key: JEXL-258
> URL: https://issues.apache.org/jira/browse/JEXL-258
> Project: Commons JEXL
>  Issue Type: Improvement
>Affects Versions: 3.1
>Reporter: Osy
>Priority: Minor
>
> Currently we have a set method to put in context a new expresion variable.
>   
> *void org.apache.commons.jexl3.JexlContext.set(String arg0, Object arg1)*
>  
>  However, I have the need of clean some variables for each Iteration, so 
> please analyze if is possible to add an unset method to do the opposite 
> action to set method.
>   



--
This message was sent by Atlassian JIRA
(v7.6.3#76005)

[jira] [Created] (JEXL-258) JEXL unset method

2018-04-11 Thread Osy (JIRA) 
Osy created JEXL-258:


 Summary: JEXL unset method
 Key: JEXL-258
 URL: https://issues.apache.org/jira/browse/JEXL-258
 Project: Commons JEXL
  Issue Type: Improvement
Affects Versions: 3.1
Reporter: Osy


Currently we have a set method to put in context a new expresion variable.
 
*void 
[org|eclipse-javadoc:%E2%98%82=IceExpre/C:%5C/Users%5C/ossoto%5C/.m2%5C/repository%5C/org%5C/apache%5C/commons%5C/commons-jexl3%5C/3.1%5C/commons-jexl3-3.1.jar%3Corg].[apache|eclipse-javadoc:%E2%98%82=IceExpre/C:%5C/Users%5C/ossoto%5C/.m2%5C/repository%5C/org%5C/apache%5C/commons%5C/commons-jexl3%5C/3.1%5C/commons-jexl3-3.1.jar%3Corg.apache].[commons|eclipse-javadoc:%E2%98%82=IceExpre/C:%5C/Users%5C/ossoto%5C/.m2%5C/repository%5C/org%5C/apache%5C/commons%5C/commons-jexl3%5C/3.1%5C/commons-jexl3-3.1.jar%3Corg.apache.commons].[jexl3|eclipse-javadoc:%E2%98%82=IceExpre/C:%5C/Users%5C/ossoto%5C/.m2%5C/repository%5C/org%5C/apache%5C/commons%5C/commons-jexl3%5C/3.1%5C/commons-jexl3-3.1.jar%3Corg.apache.commons.jexl3].[JexlContext|eclipse-javadoc:%E2%98%82=IceExpre/C:%5C/Users%5C/ossoto%5C/.m2%5C/repository%5C/org%5C/apache%5C/commons%5C/commons-jexl3%5C/3.1%5C/commons-jexl3-3.1.jar%3Corg.apache.commons.jexl3(JexlContext.class%E2%98%83JexlContext].set([String|eclipse-javadoc:%E2%98%82=IceExpre/C:%5C/Users%5C/ossoto%5C/.m2%5C/repository%5C/org%5C/apache%5C/commons%5C/commons-jexl3%5C/3.1%5C/commons-jexl3-3.1.jar%3Corg.apache.commons.jexl3(JexlContext.class%E2%98%83JexlContext~set~Ljava.lang.String;~Ljava.lang.Object;%E2%98%82java.lang.String]
 arg0, 
[Object|eclipse-javadoc:%E2%98%82=IceExpre/C:%5C/Users%5C/ossoto%5C/.m2%5C/repository%5C/org%5C/apache%5C/commons%5C/commons-jexl3%5C/3.1%5C/commons-jexl3-3.1.jar%3Corg.apache.commons.jexl3(JexlContext.class%E2%98%83JexlContext~set~Ljava.lang.String;~Ljava.lang.Object;%E2%98%82java.lang.Object]
 arg1)*
 
However, I have the need of clean some variables for each Iteration, so please 
analyze if is possible to add an unset method to do the opposite action to set 
method.
 



--
This message was sent by Atlassian JIRA
(v7.6.3#76005)

[jira] [Commented] (NET-405) Support for IPv6 in SubnetUtils

2018-04-11 Thread Lyudmila Fokina (JIRA) 

[ 
https://issues.apache.org/jira/browse/NET-405?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16434605#comment-16434605
 ] 

Lyudmila Fokina commented on NET-405:
-

Hi [~Umoxfo]

Any update on this one? I see the changed was checked-in. Any idea when the new 
version of the package is going to be available?

> Support for IPv6 in SubnetUtils
> ---
>
> Key: NET-405
> URL: https://issues.apache.org/jira/browse/NET-405
> Project: Commons Net
>  Issue Type: Improvement
>Reporter: Marc Lefrancois
>Priority: Major
>
> Currently, we cannot use org.apache.commons.net.util.SubnetUtils with IPv6 
> addresses. This class will become less and less useful as more internet 
> device are only assigned IPv6 addresses since all available IPv4 address 
> blocks have now been attributed. 
> http://en.wikipedia.org/wiki/IPv4_address_exhaustion



--
This message was sent by Atlassian JIRA
(v7.6.3#76005)

[jira] [Commented] (LANG-1390) StringUtils.join() with support for List with configurable start/end indices

2018-04-11 Thread ASF GitHub Bot (JIRA) 

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

ASF GitHub Bot commented on LANG-1390:
--

Github user coveralls commented on the issue:

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

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

Coverage decreased (-0.05%) to 95.091% when pulling 
**d6e8fbcdd2559d2fd53aa031ec5c7a21cda7c0f8 on joschi:LANG-1390** into 
**b41e91818614c2f1ac8f5e745f8bed342e80e727 on apache:master**.



> StringUtils.join() with support for List with configurable start/end 
> indices
> ---
>
> Key: LANG-1390
> URL: https://issues.apache.org/jira/browse/LANG-1390
> Project: Commons Lang
>  Issue Type: Improvement
>  Components: lang.*
>Affects Versions: 3.7
>Reporter: Jochen Schalanda
>Priority: Minor
>
> Apache Commons Lang offers a variant of the 
> [StringUtils#join()|https://commons.apache.org/proper/commons-lang/javadocs/api-3.7/org/apache/commons/lang3/StringUtils.html#join-java.lang.Object:A-java.lang.String-int-int-]
>  function which allows specifying the start and end indices which should be 
> used to concatenate the elements.
> Unfortunately, this method only works for arrays (as of Apache Commons Lang 
> 3.7) but not for lists 
> ([java.util.List|https://docs.oracle.com/javase/8/docs/api/java/util/List.html]).



--
This message was sent by Atlassian JIRA
(v7.6.3#76005)

[GitHub] commons-lang issue #324: LANG-1390: StringUtils#join() for List

2018-04-11 Thread coveralls 
Github user coveralls commented on the issue:

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

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

Coverage decreased (-0.05%) to 95.091% when pulling 
**d6e8fbcdd2559d2fd53aa031ec5c7a21cda7c0f8 on joschi:LANG-1390** into 
**b41e91818614c2f1ac8f5e745f8bed342e80e727 on apache:master**.



---

[jira] [Created] (VFS-659) Inconsistent behavior with VFS.isUriStyle setting

2018-04-11 Thread Carl Eric Codere (JIRA) 
Carl Eric Codere created VFS-659:


 Summary: Inconsistent behavior with VFS.isUriStyle setting
 Key: VFS-659
 URL: https://issues.apache.org/jira/browse/VFS-659
 Project: Commons VFS
  Issue Type: Bug
Affects Versions: 2.1
Reporter: Carl Eric Codere
 Attachments: AbstractFileName.patch

When enabling the VFS.isUriStyle setting to have URI formats containing a 
trailing SEPARATOR_CHAR when the FileObject points to a directory, I discovered 
that filename parsing would not work as expected.
 * getParent() does not seem to return the correct parent in the URI.
 * getPath() would sometimes lead to a double SEPARATOR_CHAR returned (I am not 
sure but this patch could possible issues in SMB parsing?)
 * createURI() would also return an invalid value, but maybe this patch might 
break the non URI style configuration.

I have included the patch in attachment, maybe it will be of some use to 
someone, but please double check it before applying, as my objective was to 
make it work in my use-case.



--
This message was sent by Atlassian JIRA
(v7.6.3#76005)

[jira] [Commented] (LANG-1390) StringUtils.join() with support for List with configurable start/end indices

2018-04-11 Thread ASF GitHub Bot (JIRA) 

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

ASF GitHub Bot commented on LANG-1390:
--

GitHub user joschi opened a pull request:

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

LANG-1390: StringUtils#join() for List

This pull request implements two variants of the `StringUtils#join()` 
method which work on lists (`java.util.List`) and allow specifying the start 
and end indices of the elements to join.

Refs https://issues.apache.org/jira/browse/LANG-1390

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

$ git pull https://github.com/joschi/commons-lang LANG-1390

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

https://github.com/apache/commons-lang/pull/324.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 #324


commit d6e8fbcdd2559d2fd53aa031ec5c7a21cda7c0f8
Author: Jochen Schalanda 
Date:   2018-04-11T18:27:05Z

LANG-1390: StringUtils#join() for List




> StringUtils.join() with support for List with configurable start/end 
> indices
> ---
>
> Key: LANG-1390
> URL: https://issues.apache.org/jira/browse/LANG-1390
> Project: Commons Lang
>  Issue Type: Improvement
>  Components: lang.*
>Affects Versions: 3.7
>Reporter: Jochen Schalanda
>Priority: Minor
>
> Apache Commons Lang offers a variant of the 
> [StringUtils#join()|https://commons.apache.org/proper/commons-lang/javadocs/api-3.7/org/apache/commons/lang3/StringUtils.html#join-java.lang.Object:A-java.lang.String-int-int-]
>  function which allows specifying the start and end indices which should be 
> used to concatenate the elements.
> Unfortunately, this method only works for arrays (as of Apache Commons Lang 
> 3.7) but not for lists 
> ([java.util.List|https://docs.oracle.com/javase/8/docs/api/java/util/List.html]).



--
This message was sent by Atlassian JIRA
(v7.6.3#76005)

[GitHub] commons-lang pull request #324: LANG-1390: StringUtils#join() for List

2018-04-11 Thread joschi 
GitHub user joschi opened a pull request:

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

LANG-1390: StringUtils#join() for List

This pull request implements two variants of the `StringUtils#join()` 
method which work on lists (`java.util.List`) and allow specifying the start 
and end indices of the elements to join.

Refs https://issues.apache.org/jira/browse/LANG-1390

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

$ git pull https://github.com/joschi/commons-lang LANG-1390

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

https://github.com/apache/commons-lang/pull/324.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 #324


commit d6e8fbcdd2559d2fd53aa031ec5c7a21cda7c0f8
Author: Jochen Schalanda 
Date:   2018-04-11T18:27:05Z

LANG-1390: StringUtils#join() for List




---

[jira] [Created] (LANG-1390) StringUtils.join() with support for List with configurable start/end indices

2018-04-11 Thread Jochen Schalanda (JIRA) 
Jochen Schalanda created LANG-1390:
--

 Summary: StringUtils.join() with support for List with 
configurable start/end indices
 Key: LANG-1390
 URL: https://issues.apache.org/jira/browse/LANG-1390
 Project: Commons Lang
  Issue Type: Improvement
  Components: lang.*
Affects Versions: 3.7
Reporter: Jochen Schalanda


Apache Commons Lang offers a variant of the 
[StringUtils#join()|https://commons.apache.org/proper/commons-lang/javadocs/api-3.7/org/apache/commons/lang3/StringUtils.html#join-java.lang.Object:A-java.lang.String-int-int-]
 function which allows specifying the start and end indices which should be 
used to concatenate the elements.

Unfortunately, this method only works for arrays (as of Apache Commons Lang 
3.7) but not for lists 
([java.util.List|https://docs.oracle.com/javase/8/docs/api/java/util/List.html]).



--
This message was sent by Atlassian JIRA
(v7.6.3#76005)

[jira] [Commented] (JEXL-256) Jexl should not try to resolve a variable from Context when Context.has() returns false

2018-04-11 Thread Henri Biestro (JIRA) 

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

Henri Biestro commented on JEXL-256:


Instead of IllegalArgumentException, you may throw a JexlException from your 
overridden set method, that'll do the trick. I've committed a test to verify 
the behavior in the trunk in Issues200Test.test256(...).

> Jexl should not try to resolve a variable from Context when Context.has() 
> returns false
> ---
>
> Key: JEXL-256
> URL: https://issues.apache.org/jira/browse/JEXL-256
> Project: Commons JEXL
>  Issue Type: Improvement
>Affects Versions: 3.1
>Reporter: Dmitri Blinov
>Priority: Major
>
> I have bumped into the problem when my {{Context.get()}} sometimes reports 
> access to variables that are reported by the {{Context.has()}} method as not 
> existent, and are not supposed to be in the context, mainly parts of ant-ish 
> variable paths. I assume that once {{Context.has()}} have reported {{false}} 
> no attempt from the Jexl to call {{Context.get()}} with the same parameter 
> should be made.
> I think the problem lies in {{Interpreter.java}} which first calls 
> {{Context.get()}} and only if it returns null, which should not necceserily 
> mean the variable does not exist, checks {{Context.has()}}. 
> {code}
> @Override
> protected Object visit(ASTIdentifier node, Object data) {
> cancelCheck(node);
> String name = node.getName();
> if (data == null) {
> int symbol = node.getSymbol();
> if (symbol >= 0) {
> return frame.get(symbol);
> }
> Object value = context.get(name);
> if (value == null
> && !(node.jjtGetParent() instanceof ASTReference)
> && !context.has(name)
> && !node.isTernaryProtected()) {
> return unsolvableVariable(node, name, true);
> }
> return value;
> } else {
> return getAttribute(data, name, node);
> }
> }
> {code}
> So I suggest to change the code to something like this
> {code}
> @Override
> protected Object visit(ASTIdentifier node, Object data) {
> cancelCheck(node);
> String name = node.getName();
> if (data == null) {
> int symbol = node.getSymbol();
> if (symbol >= 0) {
> return frame.get(symbol);
> }
> if (!context.has(name)
> && !(node.jjtGetParent() instanceof ASTReference)
> && !node.isTernaryProtected()) {
> return unsolvableVariable(node, name, true);
> }
> return context.get(name);
> } else {
> return getAttribute(data, name, node);
> }
> }
> {code}



--
This message was sent by Atlassian JIRA
(v7.6.3#76005)

[jira] [Comment Edited] (IO-574) Add Writes of Primitive Values To OutputStream

2018-04-11 Thread Gary Gregory (JIRA) 

[ 
https://issues.apache.org/jira/browse/IO-574?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16434560#comment-16434560
 ] 

Gary Gregory edited comment on IO-574 at 4/11/18 8:48 PM:
--

Note: We have this kind of code in {{org.apache.commons.io.EndianUtils}}. Where 
would we put this?

It seems like we need an Endian enum with BIG, MIDDLE, and LITTLE and 
implementation of read and write methods...


was (Author: garydgregory):
Note: We have this kind of code in {{org.apache.commons.io.EndianUtils}}. Where 
would we put this?

It seems like we need an Endian enum class with BIG, MIDDLE, and LITTLE and 
implementation of read and write methods...

> Add Writes of Primitive Values To OutputStream
> --
>
> Key: IO-574
> URL: https://issues.apache.org/jira/browse/IO-574
> Project: Commons IO
>  Issue Type: New Feature
>  Components: Utilities
>Affects Versions: 2.6
>Reporter: BELUGA BEHR
>Priority: Major
>
> Add the capability to serialize Java primitives to OutputStream classes.
>  
> {code:java}
> public static void writeInt(OutputStream out, int v) throws IOException {
>   out.write((byte) (0xff & (v >> 24)));
>   out.write((byte) (0xff & (v >> 16)));
>   out.write((byte) (0xff & (v >> 8)));
>   out.write((byte) (0xff & v));
> }{code}
>  
> [https://github.com/apache/hbase/blob/c3b4f788b16ac4e0e8cfd319f495308ba4d158f5/hbase-common/src/main/java/org/apache/hadoop/hbase/io/util/StreamUtils.java#L215-L243]
> [https://stackoverflow.com/questions/6374915/java-convert-int-to-byte-array-of-4-bytes]
>  
> Could also create a Serialize object that has an internal buffer that the 
> bytes are written to before calling {{out.write(buf)}} once.



--
This message was sent by Atlassian JIRA
(v7.6.3#76005)

[jira] [Commented] (IO-574) Add Writes of Primitive Values To OutputStream

2018-04-11 Thread Gary Gregory (JIRA) 

[ 
https://issues.apache.org/jira/browse/IO-574?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16434560#comment-16434560
 ] 

Gary Gregory commented on IO-574:
-

Note: We have this kind of code in {{org.apache.commons.io.EndianUtils}}. Where 
would we put this?

It seems like we need an Endian enum class with BIG, MIDDLE, and LITTLE and 
implementation of read and write methods...

> Add Writes of Primitive Values To OutputStream
> --
>
> Key: IO-574
> URL: https://issues.apache.org/jira/browse/IO-574
> Project: Commons IO
>  Issue Type: New Feature
>  Components: Utilities
>Affects Versions: 2.6
>Reporter: BELUGA BEHR
>Priority: Major
>
> Add the capability to serialize Java primitives to OutputStream classes.
>  
> {code:java}
> public static void writeInt(OutputStream out, int v) throws IOException {
>   out.write((byte) (0xff & (v >> 24)));
>   out.write((byte) (0xff & (v >> 16)));
>   out.write((byte) (0xff & (v >> 8)));
>   out.write((byte) (0xff & v));
> }{code}
>  
> [https://github.com/apache/hbase/blob/c3b4f788b16ac4e0e8cfd319f495308ba4d158f5/hbase-common/src/main/java/org/apache/hadoop/hbase/io/util/StreamUtils.java#L215-L243]
> [https://stackoverflow.com/questions/6374915/java-convert-int-to-byte-array-of-4-bytes]
>  
> Could also create a Serialize object that has an internal buffer that the 
> bytes are written to before calling {{out.write(buf)}} once.



--
This message was sent by Atlassian JIRA
(v7.6.3#76005)

[jira] [Commented] (DBCP-484) Connection leak during XATransaction in high load

2018-04-11 Thread Gary Gregory (JIRA) 

[ 
https://issues.apache.org/jira/browse/DBCP-484?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16434549#comment-16434549
 ] 

Gary Gregory commented on DBCP-484:
---

Nice find in Apache MQ [~zhfeng]! 

I'm curious if anyone in our community has any thoughts here? Because Apache MQ 
uses it in their tests does not make it right, but I would hope that they've 
validated this dependency...

Gary

> Connection leak during XATransaction in high load
> -
>
> Key: DBCP-484
> URL: https://issues.apache.org/jira/browse/DBCP-484
> Project: Commons Dbcp
>  Issue Type: Bug
>Affects Versions: 2.2.0
>Reporter: Emanuel Freitas
>Priority: Major
> Attachments: dbcp-test.zip
>
>
> We're experiencing a connection leak in a distributed transaction when the 
> system is under heavy load. We're using commons-dbcp (latest version) + 
> eclipselink and narayana to perform transaction coordination.
> From time to time we can see a stacktrace reporting an abandoned connection. 
> We are trying to figure out what's the root cause and we think that might be 
> some issue in the commons dbcp (not sure) . More specifically, this parte of 
> the code:
> ManagedConnection#updateTransactionStatus
> {code:java}
> if (transactionContext != null) {
> if (transactionContext.isActive()) {
> if (transactionContext != 
> transactionRegistry.getActiveTransactionContext()) {
> throw new SQLException("Connection can not be used while enlisted 
> in another transaction");
> }
> return;
> }
> // transaction should have been cleared up by TransactionContextListener, 
> but in
> // rare cases another lister could have registered which uses the 
> connection before
> // our listener is called.  In that rare case, trigger the transaction 
> complete call now
> transactionComplete();
> }{code}
>  
> If the transactionContext is different than null but the state is not 
> "active" (ex: STATUS_ROLLEDBACK, STATUS_ROLLING_BACK, etc) it executes the 
> transactionComplete mothod that clears the reference to a shared connection 
> and after that the connection is never closed (returned to the pool). 
>  
> If we move the transactionComplete(); to an else,(see below), the connection 
> leak does not happen.
> {code:java}
> if (transactionContext != null) {
> if (transactionContext.isActive()) {
> if (transactionContext != 
> transactionRegistry.getActiveTransactionContext()) {
> throw new SQLException("Connection can not be used while enlisted 
> in another transaction");
> }
> return;
> }
> } else {
> transactionComplete();
> }{code}
>  
> After this the dbcp unit tests still pass but I'm not sure about this 
> changes. Can you please check?
> Thanks
>  



--
This message was sent by Atlassian JIRA
(v7.6.3#76005)

[jira] [Comment Edited] (POOL-337) EvictionTimer does not remove cancelled tasks from the executor, leading to an IllegalStateException when the evictor attempts to evict

2018-04-11 Thread Phil Steitz (JIRA) 

[ 
https://issues.apache.org/jira/browse/POOL-337?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16433251#comment-16433251
 ] 

Phil Steitz edited comment on POOL-337 at 4/11/18 4:03 PM:
---

Sorry, I missed the unit test in the updated PR.  In my testing I did not 
configure a listener to get the swallowed exceptions.  I think the analysis is 
correct and the patch should fix the issue.  It might be good to consider a 
little refactoring that would allow the GOP to hold a reference to the task 
that it needs to cancel (i.e. change the type of the Evictor) so you would not 
need to maintain the map in the EvictionTimer.


was (Author: psteitz):
Sorry, I missed the unit test in the updated PR.  What I am still not getting 
is how the stack trace at the top can happen.  I can see how the memory leak is 
a problem and I think there is definitely a bug here, but I would like to be 
able to reproduce this directly from the GOP API, which I can't do.  The 
underlying Evictor task should get cancelled while the eviction lock is held, 
but somehow the executor is still firing it in the trace at the top.

> EvictionTimer does not remove cancelled tasks from the executor, leading to 
> an IllegalStateException when the evictor attempts to evict
> ---
>
> Key: POOL-337
> URL: https://issues.apache.org/jira/browse/POOL-337
> Project: Commons Pool
>  Issue Type: Bug
>Affects Versions: 2.5.0
>Reporter: Reinald Verheij
>Priority: Major
> Attachments: EvictionTimer.java, 
> EvictionTimer.java.original-from-2.5.0.java
>
>
> EvictionTimer does not remove cancelled tasks from the executor, leading to 
> an IllegalStateException when the evictor attempts to evict.
>  
> EvictionTimer::schedule() adds eviction tasks to the executor, but the cancel 
> does not remove it. This is asymmetric and leads to the following exception:
> {noformat}
> java.lang.IllegalStateException: Pool not open
>   at 
> org.apache.commons.pool2.impl.BaseGenericObjectPool.assertOpen(BaseGenericObjectPool.java:713)
>   at 
> org.apache.commons.pool2.impl.GenericObjectPool.evict(GenericObjectPool.java:721)
>   at 
> org.apache.commons.pool2.impl.BaseGenericObjectPool$Evictor.run(BaseGenericObjectPool.java:1077)
>   at 
> java.util.concurrent.Executors$RunnableAdapter.call(Executors.java:511)
>   at java.util.concurrent.FutureTask.runAndReset(FutureTask.java:308)
>   at 
> java.util.concurrent.ScheduledThreadPoolExecutor$ScheduledFutureTask.access$301(ScheduledThreadPoolExecutor.java:180)
>   at 
> java.util.concurrent.ScheduledThreadPoolExecutor$ScheduledFutureTask.run(ScheduledThreadPoolExecutor.java:294)
>   at 
> java.util.concurrent.ThreadPoolExecutor.runWorker(ThreadPoolExecutor.java:1149)
>   at 
> java.util.concurrent.ThreadPoolExecutor$Worker.run(ThreadPoolExecutor.java:624)
>   at java.lang.Thread.run(Thread.java:748){noformat}
> I think the cancel would need to remember the future which returned from 
> {{executor::scheduleWithFixedDelay()}} in {{schedule()}} and then do 
> something like this (see  [^EvictionTimer.java] compared to original  
> [^EvictionTimer.java.original-from-2.5.0.java] )
> {code:java}
> if (futures.containsKey(task)) {
> futures.remove(task).cancel(false);
> executor.purge();
> }{code}



--
This message was sent by Atlassian JIRA
(v7.6.3#76005)

[jira] [Comment Edited] (POOL-338) GenericObjectPool constructor throws an exception

2018-04-11 Thread Gary Gregory (JIRA) 

[ 
https://issues.apache.org/jira/browse/POOL-338?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16434096#comment-16434096
 ] 

Gary Gregory edited comment on POOL-338 at 4/11/18 3:53 PM:


Ah, yes, the ctor... please try the attached patch [^commons-pool-gg.patch]

In the 2.x version, we have to keep backward compatibility in mind. This patch 
will use the class name only if the class name is different from the default 
class name.

Gary


was (Author: garydgregory):
Ah, yes, the ctor... please try the attached patch [^commons-pool-gg.patch]

^In the 2.x version, we have to keep backward compatibility in mind. This patch 
will use the class name only if the class name is different from the default 
class name.^

Gary

> GenericObjectPool constructor throws an exception
> -
>
> Key: POOL-338
> URL: https://issues.apache.org/jira/browse/POOL-338
> Project: Commons Pool
>  Issue Type: Bug
>Affects Versions: 2.4.2, 2.4.3, 2.5.0
> Environment: Java 8, Liferay DXP (an OSGi environment).
>Reporter: Michael C
>Priority: Major
> Attachments: commons-pool-gg.patch
>
>
> Version 2.4.3 GenericObjectPool constructor throws this exception:
> {{java.lang.IllegalArgumentException: 
> [org.apache.commons.pool2.impl.DefaultEvictionPolicy] does not implement 
> EvictionPolicy}}
> {{    at 
> org.apache.commons.pool2.impl.BaseGenericObjectPool.setEvictionPolicyClassName(BaseGenericObjectPool.java:618)}}
> {{    at 
> org.apache.commons.pool2.impl.GenericObjectPool.setConfig(GenericObjectPool.java:318)}}
> {{    at 
> org.apache.commons.pool2.impl.GenericObjectPool.(GenericObjectPool.java:115)}}
> {{    at 
> org.apache.commons.pool2.impl.GenericObjectPool.(GenericObjectPool.java:88)}}
>  
> Version 2.5.0 throws the same exception. Version 2.4.2 or older's 
> setEvictionPolicyClassName method fail silently for the same reason. This 
> line in BaseGenericObjectPool evaluates to false for all versions:
> {{    if (policy instanceof EvictionPolicy) {}}
>  



--
This message was sent by Atlassian JIRA
(v7.6.3#76005)

[jira] [Comment Edited] (POOL-338) GenericObjectPool constructor throws an exception

2018-04-11 Thread Gary Gregory (JIRA) 

[ 
https://issues.apache.org/jira/browse/POOL-338?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16434096#comment-16434096
 ] 

Gary Gregory edited comment on POOL-338 at 4/11/18 3:53 PM:


Ah, yes, the ctor... please try the attached patch [^commons-pool-gg.patch]

^In the 2.x version, we have to keep backward compatibility in mind. This patch 
will use the class name only if the class name is different from the default 
class name.^

Gary


was (Author: garydgregory):
Ah, yes, the ctor... please try the attached patch [^commons-pool-gg.patch]

Gary

> GenericObjectPool constructor throws an exception
> -
>
> Key: POOL-338
> URL: https://issues.apache.org/jira/browse/POOL-338
> Project: Commons Pool
>  Issue Type: Bug
>Affects Versions: 2.4.2, 2.4.3, 2.5.0
> Environment: Java 8, Liferay DXP (an OSGi environment).
>Reporter: Michael C
>Priority: Major
> Attachments: commons-pool-gg.patch
>
>
> Version 2.4.3 GenericObjectPool constructor throws this exception:
> {{java.lang.IllegalArgumentException: 
> [org.apache.commons.pool2.impl.DefaultEvictionPolicy] does not implement 
> EvictionPolicy}}
> {{    at 
> org.apache.commons.pool2.impl.BaseGenericObjectPool.setEvictionPolicyClassName(BaseGenericObjectPool.java:618)}}
> {{    at 
> org.apache.commons.pool2.impl.GenericObjectPool.setConfig(GenericObjectPool.java:318)}}
> {{    at 
> org.apache.commons.pool2.impl.GenericObjectPool.(GenericObjectPool.java:115)}}
> {{    at 
> org.apache.commons.pool2.impl.GenericObjectPool.(GenericObjectPool.java:88)}}
>  
> Version 2.5.0 throws the same exception. Version 2.4.2 or older's 
> setEvictionPolicyClassName method fail silently for the same reason. This 
> line in BaseGenericObjectPool evaluates to false for all versions:
> {{    if (policy instanceof EvictionPolicy) {}}
>  



--
This message was sent by Atlassian JIRA
(v7.6.3#76005)

[jira] [Commented] (POOL-338) GenericObjectPool constructor throws an exception

2018-04-11 Thread Gary Gregory (JIRA) 

[ 
https://issues.apache.org/jira/browse/POOL-338?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16434096#comment-16434096
 ] 

Gary Gregory commented on POOL-338:
---

Ah, yes, the ctor... please try the attached patch [^commons-pool-gg.patch]

Gary

> GenericObjectPool constructor throws an exception
> -
>
> Key: POOL-338
> URL: https://issues.apache.org/jira/browse/POOL-338
> Project: Commons Pool
>  Issue Type: Bug
>Affects Versions: 2.4.2, 2.4.3, 2.5.0
> Environment: Java 8, Liferay DXP (an OSGi environment).
>Reporter: Michael C
>Priority: Major
> Attachments: commons-pool-gg.patch
>
>
> Version 2.4.3 GenericObjectPool constructor throws this exception:
> {{java.lang.IllegalArgumentException: 
> [org.apache.commons.pool2.impl.DefaultEvictionPolicy] does not implement 
> EvictionPolicy}}
> {{    at 
> org.apache.commons.pool2.impl.BaseGenericObjectPool.setEvictionPolicyClassName(BaseGenericObjectPool.java:618)}}
> {{    at 
> org.apache.commons.pool2.impl.GenericObjectPool.setConfig(GenericObjectPool.java:318)}}
> {{    at 
> org.apache.commons.pool2.impl.GenericObjectPool.(GenericObjectPool.java:115)}}
> {{    at 
> org.apache.commons.pool2.impl.GenericObjectPool.(GenericObjectPool.java:88)}}
>  
> Version 2.5.0 throws the same exception. Version 2.4.2 or older's 
> setEvictionPolicyClassName method fail silently for the same reason. This 
> line in BaseGenericObjectPool evaluates to false for all versions:
> {{    if (policy instanceof EvictionPolicy) {}}
>  



--
This message was sent by Atlassian JIRA
(v7.6.3#76005)

[jira] [Updated] (POOL-338) GenericObjectPool constructor throws an exception

2018-04-11 Thread Gary Gregory (JIRA) 

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

Gary Gregory updated POOL-338:
--
Attachment: commons-pool-gg.patch

> GenericObjectPool constructor throws an exception
> -
>
> Key: POOL-338
> URL: https://issues.apache.org/jira/browse/POOL-338
> Project: Commons Pool
>  Issue Type: Bug
>Affects Versions: 2.4.2, 2.4.3, 2.5.0
> Environment: Java 8, Liferay DXP (an OSGi environment).
>Reporter: Michael C
>Priority: Major
> Attachments: commons-pool-gg.patch
>
>
> Version 2.4.3 GenericObjectPool constructor throws this exception:
> {{java.lang.IllegalArgumentException: 
> [org.apache.commons.pool2.impl.DefaultEvictionPolicy] does not implement 
> EvictionPolicy}}
> {{    at 
> org.apache.commons.pool2.impl.BaseGenericObjectPool.setEvictionPolicyClassName(BaseGenericObjectPool.java:618)}}
> {{    at 
> org.apache.commons.pool2.impl.GenericObjectPool.setConfig(GenericObjectPool.java:318)}}
> {{    at 
> org.apache.commons.pool2.impl.GenericObjectPool.(GenericObjectPool.java:115)}}
> {{    at 
> org.apache.commons.pool2.impl.GenericObjectPool.(GenericObjectPool.java:88)}}
>  
> Version 2.5.0 throws the same exception. Version 2.4.2 or older's 
> setEvictionPolicyClassName method fail silently for the same reason. This 
> line in BaseGenericObjectPool evaluates to false for all versions:
> {{    if (policy instanceof EvictionPolicy) {}}
>  



--
This message was sent by Atlassian JIRA
(v7.6.3#76005)

[jira] [Resolved] (CONFIGURATION-652) FileHandler does not produce root node attributes for XMLConfiguration

2018-04-11 Thread Oliver Heger (JIRA) 

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

Oliver Heger resolved CONFIGURATION-652.

   Resolution: Fixed
Fix Version/s: 2.3

Patch applied in SVN in revision 1828908. Many thanks again.

If you want to be added to the contributors section in the pom, please send 
your personal data that should be included.

> FileHandler does not  produce root node attributes for XMLConfiguration 
> 
>
> Key: CONFIGURATION-652
> URL: https://issues.apache.org/jira/browse/CONFIGURATION-652
> Project: Commons Configuration
>  Issue Type: Bug
>  Components: Interpolation
>Affects Versions: 2.1.1, 2.2
> Environment: Java 8  on Linux
>Reporter: Claude Warren
>Priority: Major
>  Labels: namespace, xml
> Fix For: 2.3
>
> Attachments: Test.java, configuration-652.patch, 
> testChildNamespace.xml, testRootNamespace.xml
>
>
> I have a case where I need to take a Configuration file and write it as an 
> XML document.  The document should have one or more xmlns properties on the 
> root node but the xmlns attributes are not output.



--
This message was sent by Atlassian JIRA
(v7.6.3#76005)

[jira] [Updated] (JEXL-257) Function throwing IllegalArgumentException may called twice

2018-04-11 Thread Dmitri Blinov (JIRA) 

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

Dmitri Blinov updated JEXL-257:
---
Description: 
With regard to JEXL-256 I have noticed that a function which once had throw 
IllegalArgumentException may be called immediately once again in script. The 
problem is not always reproducible so I think it is somehow related to caching 
and {{tryInvoke()}} being called first and {{invoke()}} called afterwards.

I can't produce test case at the moment but try to describe on the example. I 
ommited some irrelevant details for the sake of simplicity...

First I have a function that evaluates Jexl script within script.
{code:java}
eval("java = 1")
{code}
Then I have a {{Context.set()}} that works like this
{code:java}
public void set(String name) {
if (name.equals("java"))
   throw new IllegalArgumentException("java");
...
{code}
As I stated in JEXL-256, when {{Context.set()}} throws IllegalArgumentException 
then script execution immediately terminates with this exception, and not with 
JexlException. So, the function {{eval()}} im my case terminates with 
IllegalArgumentException also.

Then I have two stack traces in the log, one for the first invocation
{quote}java.lang.IllegalArgumentException: java
 at MyDefaultContext.set(MyDefaultContext.java:279) 
 at 
org.apache.commons.jexl3.internal.Interpreter.executeAssign(Interpreter.java:1189)
 ~[commons-jexl-3.2.jar:3.2-SNAPSHOT]
 at org.apache.commons.jexl3.internal.Interpreter.visit(Interpreter.java:1094) 
~[commons-jexl-3.2.jar:3.2-SNAPSHOT]
 at 
org.apache.commons.jexl3.parser.ASTAssignment.jjtAccept(ASTAssignment.java:18) 
~[commons-jexl-3.2.jar:3.2-SNAPSHOT]
 at org.apache.commons.jexl3.internal.Interpreter.visit(Interpreter.java:890) 
~[commons-jexl-3.2.jar:3.2-SNAPSHOT]
 at 
org.apache.commons.jexl3.parser.ASTJexlScript.jjtAccept(ASTJexlScript.java:58) 
~[commons-jexl-3.2.jar:3.2-SNAPSHOT]
 at 
org.apache.commons.jexl3.internal.Interpreter.interpret(Interpreter.java:190) 
~[commons-jexl-3.2.jar:3.2-SNAPSHOT]
 at org.apache.commons.jexl3.internal.Script.execute(Script.java:185) 
~[commons-jexl-3.2.jar:3.2-SNAPSHOT]
 at EvaluationContext.evalScript(EvaluationContext.java:1078) 
 at EvaluationContext.evaluateScript(EvaluationContext.java:1043) 
 at MyDefaultContext.eval(MyDefaultContext.java:736)
 at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method) ~[?:1.8.0_162]
 at 
sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:62) 
~[?:1.8.0_162]
 at 
sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:43)
 ~[?:1.8.0_162]
 at java.lang.reflect.Method.invoke(Method.java:498) ~[?:1.8.0_162]
 at 
org.apache.commons.jexl3.internal.introspection.MethodExecutor.invoke(MethodExecutor.java:93)
 ~[commons-jexl-3.2.jar:3.2-SNAPSHOT]
 at 
org.apache.commons.jexl3.internal.introspection.MethodExecutor.tryInvoke(MethodExecutor.java:104)
 ~[commons-jexl-3.2.jar:3.2-SNAPSHOT]
 at 
org.apache.commons.jexl3.internal.Interpreter$Funcall.tryInvoke(Interpreter.java:1436)
 ~[commons-jexl-3.2.jar:3.2-SNAPSHOT]
 at org.apache.commons.jexl3.internal.Interpreter.call(Interpreter.java:1545) 
~[commons-jexl-3.2.jar:3.2-SNAPSHOT]
 at org.apache.commons.jexl3.internal.Interpreter.visit(Interpreter.java:1357) 
~[commons-jexl-3.2.jar:3.2-SNAPSHOT]
 at 
org.apache.commons.jexl3.parser.ASTFunctionNode.jjtAccept(ASTFunctionNode.java:18)
 ~[commons-jexl-3.2.jar:3.2-SNAPSHOT]
 at 
org.apache.commons.jexl3.internal.Interpreter.executeAssign(Interpreter.java:1149)
 ~[commons-jexl-3.2.jar:3.2-SNAPSHOT]
 at org.apache.commons.jexl3.internal.Interpreter.visit(Interpreter.java:1094) 
~[commons-jexl-3.2.jar:3.2-SNAPSHOT]
 at 
org.apache.commons.jexl3.parser.ASTAssignment.jjtAccept(ASTAssignment.java:18) 
~[commons-jexl-3.2.jar:3.2-SNAPSHOT]
 at 
org.apache.commons.jexl3.internal.Interpreter.processAnnotation(Interpreter.java:1907)
 ~[commons-jexl-3.2.jar:3.2-SNAPSHOT]
 at org.apache.commons.jexl3.internal.Interpreter$1.call(Interpreter.java:1917) 
~[commons-jexl-3.2.jar:3.2-SNAPSHOT]
 at 
com.msy.einie.f1.jexl.MsyDefaultContext.processAnnotation(MsyDefaultContext.java:531)
 ~[msy-1.0.jar:1.0]
 at 
org.apache.commons.jexl3.internal.Interpreter.processAnnotation(Interpreter.java:1963)
 ~[commons-jexl-3.2.jar:3.2-SNAPSHOT]
 at 
org.apache.commons.jexl3.internal.Interpreter.processAnnotation(Interpreter.java:1936)
 ~[commons-jexl-3.2.jar:3.2-SNAPSHOT]
 at org.apache.commons.jexl3.internal.Interpreter.visit(Interpreter.java:1877) 
~[commons-jexl-3.2.jar:3.2-SNAPSHOT]
 at 
org.apache.commons.jexl3.parser.ASTAnnotatedStatement.jjtAccept(ASTAnnotatedStatement.java:18)
 ~[commons-jexl-3.2.jar:3.2-SNAPSHOT]
 at org.apache.commons.jexl3.internal.Interpreter.visit(Interpreter.java:890) 
~[commons-jexl-3.2.jar:3.2-SNAPSHOT]
 at 
org.apache.commons.jexl3.parser.ASTJexlScript.jjtAccept(ASTJexlScript.java:58) 
~[commons-jexl-3.2.jar:3.2-SNAPSHOT]
 at

[jira] [Updated] (JEXL-257) Function throwing IllegalArgumentException may called twice

2018-04-11 Thread Dmitri Blinov (JIRA) 

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

Dmitri Blinov updated JEXL-257:
---
Summary: Function throwing IllegalArgumentException may called twice  (was: 
Function throwing IllegalAccessException may called twice)

> Function throwing IllegalArgumentException may called twice
> ---
>
> Key: JEXL-257
> URL: https://issues.apache.org/jira/browse/JEXL-257
> Project: Commons JEXL
>  Issue Type: Bug
>Affects Versions: 3.1
>Reporter: Dmitri Blinov
>Priority: Major
>
> With regard to JEXL-256 I have noticed that a function which once had throw 
> IllegalAccessException may be called immediately once again in script. The 
> problem is not always reproducible so I think it is somehow related to 
> caching and {{tryInvoke()}} being called first and {{invoke()}} called 
> afterwards.
> I can't produce test case at the moment but try to describe on the example. I 
> ommited some irrelevant details for the sake of simplicity...
> First I have a function that evaluates Jexl script within script.
> {code:java}
> eval("java = 1")
> {code}
> Then I have a {{Context.set()}} that works like this
> {code:java}
> public void set(String name) {
> if (name.equals("java"))
>throw new IllegalAccessException("java");
> ...
> {code}
> As I stated in JEXL-256, when {{Context.set()}} throws IllegalAccessException 
> then script execution immediately terminates with this exception, and not 
> with JexlException. So, the function {{eval()}} im my case terminates with 
> IllegalAccessException also.
> Then I have two stack traces in the log, one for the first invocation
> {quote}java.lang.IllegalArgumentException: java
>  at MyDefaultContext.set(MyDefaultContext.java:279) 
>  at 
> org.apache.commons.jexl3.internal.Interpreter.executeAssign(Interpreter.java:1189)
>  ~[commons-jexl-3.2.jar:3.2-SNAPSHOT]
>  at 
> org.apache.commons.jexl3.internal.Interpreter.visit(Interpreter.java:1094) 
> ~[commons-jexl-3.2.jar:3.2-SNAPSHOT]
>  at 
> org.apache.commons.jexl3.parser.ASTAssignment.jjtAccept(ASTAssignment.java:18)
>  ~[commons-jexl-3.2.jar:3.2-SNAPSHOT]
>  at org.apache.commons.jexl3.internal.Interpreter.visit(Interpreter.java:890) 
> ~[commons-jexl-3.2.jar:3.2-SNAPSHOT]
>  at 
> org.apache.commons.jexl3.parser.ASTJexlScript.jjtAccept(ASTJexlScript.java:58)
>  ~[commons-jexl-3.2.jar:3.2-SNAPSHOT]
>  at 
> org.apache.commons.jexl3.internal.Interpreter.interpret(Interpreter.java:190) 
> ~[commons-jexl-3.2.jar:3.2-SNAPSHOT]
>  at org.apache.commons.jexl3.internal.Script.execute(Script.java:185) 
> ~[commons-jexl-3.2.jar:3.2-SNAPSHOT]
>  at EvaluationContext.evalScript(EvaluationContext.java:1078) 
>  at EvaluationContext.evaluateScript(EvaluationContext.java:1043) 
>  at MyDefaultContext.eval(MyDefaultContext.java:736)
>  at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method) ~[?:1.8.0_162]
>  at 
> sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:62) 
> ~[?:1.8.0_162]
>  at 
> sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:43)
>  ~[?:1.8.0_162]
>  at java.lang.reflect.Method.invoke(Method.java:498) ~[?:1.8.0_162]
>  at 
> org.apache.commons.jexl3.internal.introspection.MethodExecutor.invoke(MethodExecutor.java:93)
>  ~[commons-jexl-3.2.jar:3.2-SNAPSHOT]
>  at 
> org.apache.commons.jexl3.internal.introspection.MethodExecutor.tryInvoke(MethodExecutor.java:104)
>  ~[commons-jexl-3.2.jar:3.2-SNAPSHOT]
>  at 
> org.apache.commons.jexl3.internal.Interpreter$Funcall.tryInvoke(Interpreter.java:1436)
>  ~[commons-jexl-3.2.jar:3.2-SNAPSHOT]
>  at org.apache.commons.jexl3.internal.Interpreter.call(Interpreter.java:1545) 
> ~[commons-jexl-3.2.jar:3.2-SNAPSHOT]
>  at 
> org.apache.commons.jexl3.internal.Interpreter.visit(Interpreter.java:1357) 
> ~[commons-jexl-3.2.jar:3.2-SNAPSHOT]
>  at 
> org.apache.commons.jexl3.parser.ASTFunctionNode.jjtAccept(ASTFunctionNode.java:18)
>  ~[commons-jexl-3.2.jar:3.2-SNAPSHOT]
>  at 
> org.apache.commons.jexl3.internal.Interpreter.executeAssign(Interpreter.java:1149)
>  ~[commons-jexl-3.2.jar:3.2-SNAPSHOT]
>  at 
> org.apache.commons.jexl3.internal.Interpreter.visit(Interpreter.java:1094) 
> ~[commons-jexl-3.2.jar:3.2-SNAPSHOT]
>  at 
> org.apache.commons.jexl3.parser.ASTAssignment.jjtAccept(ASTAssignment.java:18)
>  ~[commons-jexl-3.2.jar:3.2-SNAPSHOT]
>  at 
> org.apache.commons.jexl3.internal.Interpreter.processAnnotation(Interpreter.java:1907)
>  ~[commons-jexl-3.2.jar:3.2-SNAPSHOT]
>  at 
> org.apache.commons.jexl3.internal.Interpreter$1.call(Interpreter.java:1917) 
> ~[commons-jexl-3.2.jar:3.2-SNAPSHOT]
>  at 
> com.msy.einie.f1.jexl.MsyDefaultContext.processAnnotation(MsyDefaultContext.java:531)
>  ~[msy-1.0.jar:1.0]
>  at 
>

[jira] [Created] (JEXL-257) Function throwing IllegalAccessException may called twice

2018-04-11 Thread Dmitri Blinov (JIRA) 
Dmitri Blinov created JEXL-257:
--

 Summary: Function throwing IllegalAccessException may called twice
 Key: JEXL-257
 URL: https://issues.apache.org/jira/browse/JEXL-257
 Project: Commons JEXL
  Issue Type: Bug
Affects Versions: 3.1
Reporter: Dmitri Blinov


With regard to JEXL-256 I have noticed that a function which once had throw 
IllegalAccessException may be called immediately once again in script. The 
problem is not always reproducible so I think it is somehow related to caching 
and {{tryInvoke()}} being called first and {{invoke()}} called afterwards.

I can't produce test case at the moment but try to describe on the example. I 
ommited some irrelevant details for the sake of simplicity...

First I have a function that evaluates Jexl script within script.
{code:java}
eval("java = 1")
{code}
Then I have a {{Context.set()}} that works like this
{code:java}
public void set(String name) {
if (name.equals("java"))
   throw new IllegalAccessException("java");
...
{code}
As I stated in JEXL-256, when {{Context.set()}} throws IllegalAccessException 
then script execution immediately terminates with this exception, and not with 
JexlException. So, the function {{eval()}} im my case terminates with 
IllegalAccessException also.

Then I have two stack traces in the log, one for the first invocation
{quote}java.lang.IllegalArgumentException: java
 at MyDefaultContext.set(MyDefaultContext.java:279) 
 at 
org.apache.commons.jexl3.internal.Interpreter.executeAssign(Interpreter.java:1189)
 ~[commons-jexl-3.2.jar:3.2-SNAPSHOT]
 at org.apache.commons.jexl3.internal.Interpreter.visit(Interpreter.java:1094) 
~[commons-jexl-3.2.jar:3.2-SNAPSHOT]
 at 
org.apache.commons.jexl3.parser.ASTAssignment.jjtAccept(ASTAssignment.java:18) 
~[commons-jexl-3.2.jar:3.2-SNAPSHOT]
 at org.apache.commons.jexl3.internal.Interpreter.visit(Interpreter.java:890) 
~[commons-jexl-3.2.jar:3.2-SNAPSHOT]
 at 
org.apache.commons.jexl3.parser.ASTJexlScript.jjtAccept(ASTJexlScript.java:58) 
~[commons-jexl-3.2.jar:3.2-SNAPSHOT]
 at 
org.apache.commons.jexl3.internal.Interpreter.interpret(Interpreter.java:190) 
~[commons-jexl-3.2.jar:3.2-SNAPSHOT]
 at org.apache.commons.jexl3.internal.Script.execute(Script.java:185) 
~[commons-jexl-3.2.jar:3.2-SNAPSHOT]
 at EvaluationContext.evalScript(EvaluationContext.java:1078) 
 at EvaluationContext.evaluateScript(EvaluationContext.java:1043) 
 at MyDefaultContext.eval(MyDefaultContext.java:736)
 at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method) ~[?:1.8.0_162]
 at 
sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:62) 
~[?:1.8.0_162]
 at 
sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:43)
 ~[?:1.8.0_162]
 at java.lang.reflect.Method.invoke(Method.java:498) ~[?:1.8.0_162]
 at 
org.apache.commons.jexl3.internal.introspection.MethodExecutor.invoke(MethodExecutor.java:93)
 ~[commons-jexl-3.2.jar:3.2-SNAPSHOT]
 at 
org.apache.commons.jexl3.internal.introspection.MethodExecutor.tryInvoke(MethodExecutor.java:104)
 ~[commons-jexl-3.2.jar:3.2-SNAPSHOT]
 at 
org.apache.commons.jexl3.internal.Interpreter$Funcall.tryInvoke(Interpreter.java:1436)
 ~[commons-jexl-3.2.jar:3.2-SNAPSHOT]
 at org.apache.commons.jexl3.internal.Interpreter.call(Interpreter.java:1545) 
~[commons-jexl-3.2.jar:3.2-SNAPSHOT]
 at org.apache.commons.jexl3.internal.Interpreter.visit(Interpreter.java:1357) 
~[commons-jexl-3.2.jar:3.2-SNAPSHOT]
 at 
org.apache.commons.jexl3.parser.ASTFunctionNode.jjtAccept(ASTFunctionNode.java:18)
 ~[commons-jexl-3.2.jar:3.2-SNAPSHOT]
 at 
org.apache.commons.jexl3.internal.Interpreter.executeAssign(Interpreter.java:1149)
 ~[commons-jexl-3.2.jar:3.2-SNAPSHOT]
 at org.apache.commons.jexl3.internal.Interpreter.visit(Interpreter.java:1094) 
~[commons-jexl-3.2.jar:3.2-SNAPSHOT]
 at 
org.apache.commons.jexl3.parser.ASTAssignment.jjtAccept(ASTAssignment.java:18) 
~[commons-jexl-3.2.jar:3.2-SNAPSHOT]
 at 
org.apache.commons.jexl3.internal.Interpreter.processAnnotation(Interpreter.java:1907)
 ~[commons-jexl-3.2.jar:3.2-SNAPSHOT]
 at org.apache.commons.jexl3.internal.Interpreter$1.call(Interpreter.java:1917) 
~[commons-jexl-3.2.jar:3.2-SNAPSHOT]
 at 
com.msy.einie.f1.jexl.MsyDefaultContext.processAnnotation(MsyDefaultContext.java:531)
 ~[msy-1.0.jar:1.0]
 at 
org.apache.commons.jexl3.internal.Interpreter.processAnnotation(Interpreter.java:1963)
 ~[commons-jexl-3.2.jar:3.2-SNAPSHOT]
 at 
org.apache.commons.jexl3.internal.Interpreter.processAnnotation(Interpreter.java:1936)
 ~[commons-jexl-3.2.jar:3.2-SNAPSHOT]
 at org.apache.commons.jexl3.internal.Interpreter.visit(Interpreter.java:1877) 
~[commons-jexl-3.2.jar:3.2-SNAPSHOT]
 at 
org.apache.commons.jexl3.parser.ASTAnnotatedStatement.jjtAccept(ASTAnnotatedStatement.java:18)
 ~[commons-jexl-3.2.jar:3.2-SNAPSHOT]
 at org.apache.commons.jexl3.internal.Interpreter.visit(Interpreter.java:890)

[jira] [Commented] (JEXL-256) Jexl should not try to resolve a variable from Context when Context.has() returns false

2018-04-11 Thread Dmitri Blinov (JIRA) 

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

Dmitri Blinov commented on JEXL-256:


I have figured out how to overcome this issue without changing Jexl, I simply 
need to restrict the usage of context variable names that, in my case, are 
well-known prefixes of my ant-ish variables, which makes sence to do anyway. 
So, for example, when {{java.lang.Double}} is need to be resolved, I should 
restrict the use of {{java}} variable name, and return {{null}} in {{get()}} 
and {{false}} in {{has()}}. The only problem now is that I also want to restict 
assigning anything to such a variable, so {{java = 1}} would be illegal to use 
inside script. I tried to throw {{IllegalArgumentException}} inside 
{{Context.set()}} but somehow Jexl does not catch this and passes this 
exception without wrapping it with JexlException, which makes me suspect this 
is not right thing to do. Is there a better way we can prevent context from 
setting values to certain names?

> Jexl should not try to resolve a variable from Context when Context.has() 
> returns false
> ---
>
> Key: JEXL-256
> URL: https://issues.apache.org/jira/browse/JEXL-256
> Project: Commons JEXL
>  Issue Type: Improvement
>Affects Versions: 3.1
>Reporter: Dmitri Blinov
>Priority: Major
>
> I have bumped into the problem when my {{Context.get()}} sometimes reports 
> access to variables that are reported by the {{Context.has()}} method as not 
> existent, and are not supposed to be in the context, mainly parts of ant-ish 
> variable paths. I assume that once {{Context.has()}} have reported {{false}} 
> no attempt from the Jexl to call {{Context.get()}} with the same parameter 
> should be made.
> I think the problem lies in {{Interpreter.java}} which first calls 
> {{Context.get()}} and only if it returns null, which should not necceserily 
> mean the variable does not exist, checks {{Context.has()}}. 
> {code}
> @Override
> protected Object visit(ASTIdentifier node, Object data) {
> cancelCheck(node);
> String name = node.getName();
> if (data == null) {
> int symbol = node.getSymbol();
> if (symbol >= 0) {
> return frame.get(symbol);
> }
> Object value = context.get(name);
> if (value == null
> && !(node.jjtGetParent() instanceof ASTReference)
> && !context.has(name)
> && !node.isTernaryProtected()) {
> return unsolvableVariable(node, name, true);
> }
> return value;
> } else {
> return getAttribute(data, name, node);
> }
> }
> {code}
> So I suggest to change the code to something like this
> {code}
> @Override
> protected Object visit(ASTIdentifier node, Object data) {
> cancelCheck(node);
> String name = node.getName();
> if (data == null) {
> int symbol = node.getSymbol();
> if (symbol >= 0) {
> return frame.get(symbol);
> }
> if (!context.has(name)
> && !(node.jjtGetParent() instanceof ASTReference)
> && !node.isTernaryProtected()) {
> return unsolvableVariable(node, name, true);
> }
> return context.get(name);
> } else {
> return getAttribute(data, name, node);
> }
> }
> {code}



--
This message was sent by Atlassian JIRA
(v7.6.3#76005)

[jira] [Resolved] (JEXL-255) Ability to continue interrupted scripts

2018-04-11 Thread Dmitri Blinov (JIRA) 

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

Dmitri Blinov resolved JEXL-255.

Resolution: Fixed

> Ability to continue interrupted scripts
> ---
>
> Key: JEXL-255
> URL: https://issues.apache.org/jira/browse/JEXL-255
> Project: Commons JEXL
>  Issue Type: Improvement
>Affects Versions: 3.1
>Reporter: Dmitri Blinov
>Assignee: Henri Biestro
>Priority: Major
> Fix For: 3.2
>
>
> I'm trying to implement the {{@timeout}} annotation that should work like the 
> following
> {code:java}
> @timeout(15000) { return longrunningcall(); }
>  {code}
> The idea is to protect part of the script code from being executed 
> indefinitely or more than allowed by business rules. The script should 
> continue its evaluation after the {{@timeout}} annotation regardless of 
> whether the timeout has taken place or not.
> There is a straightforward implementation that starts guarding thread which 
> should invoke {{Thread.interrupt()}} for the thread executing the script. The 
> {{InterruptedException | JexlException.Cancel}} is then caught and swallowed 
> inside the {{processAnnotation()}} method, and if the guard thread has fired, 
> which means the timeout occured, the {{null}} value is returned.
> I expected the script to continue its evaluation after the exception is 
> processed inside {{processAnnotation()}} code, but the script nevertheless 
> throwed {{JexlException.Cancel}} as a result. The suggestion is to allow 
> script to continue its evaluation once {{InterruptedException}} or 
> {{JexlException.Cancel}} is processed. 



--
This message was sent by Atlassian JIRA
(v7.6.3#76005)

[jira] [Commented] (CONFIGURATION-652) FileHandler does not produce root node attributes for XMLConfiguration

2018-04-11 Thread Claude Warren (JIRA) 

[ 
https://issues.apache.org/jira/browse/CONFIGURATION-652?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16433524#comment-16433524
 ] 

Claude Warren commented on CONFIGURATION-652:
-

Arrrggg... yes, I managed to miss them.  I have attached them to the Jira both 
go into the src/test/resources directory.

> FileHandler does not  produce root node attributes for XMLConfiguration 
> 
>
> Key: CONFIGURATION-652
> URL: https://issues.apache.org/jira/browse/CONFIGURATION-652
> Project: Commons Configuration
>  Issue Type: Bug
>  Components: Interpolation
>Affects Versions: 2.1.1, 2.2
> Environment: Java 8  on Linux
>Reporter: Claude Warren
>Priority: Major
>  Labels: namespace, xml
> Attachments: Test.java, configuration-652.patch, 
> testChildNamespace.xml, testRootNamespace.xml
>
>
> I have a case where I need to take a Configuration file and write it as an 
> XML document.  The document should have one or more xmlns properties on the 
> root node but the xmlns attributes are not output.



--
This message was sent by Atlassian JIRA
(v7.6.3#76005)

[jira] [Updated] (CONFIGURATION-652) FileHandler does not produce root node attributes for XMLConfiguration

2018-04-11 Thread Claude Warren (JIRA) 

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

Claude Warren updated CONFIGURATION-652:

Attachment: testRootNamespace.xml

> FileHandler does not  produce root node attributes for XMLConfiguration 
> 
>
> Key: CONFIGURATION-652
> URL: https://issues.apache.org/jira/browse/CONFIGURATION-652
> Project: Commons Configuration
>  Issue Type: Bug
>  Components: Interpolation
>Affects Versions: 2.1.1, 2.2
> Environment: Java 8  on Linux
>Reporter: Claude Warren
>Priority: Major
>  Labels: namespace, xml
> Attachments: Test.java, configuration-652.patch, 
> testChildNamespace.xml, testRootNamespace.xml
>
>
> I have a case where I need to take a Configuration file and write it as an 
> XML document.  The document should have one or more xmlns properties on the 
> root node but the xmlns attributes are not output.



--
This message was sent by Atlassian JIRA
(v7.6.3#76005)

[jira] [Updated] (CONFIGURATION-652) FileHandler does not produce root node attributes for XMLConfiguration

2018-04-11 Thread Claude Warren (JIRA) 

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

Claude Warren updated CONFIGURATION-652:

Attachment: testChildNamespace.xml

> FileHandler does not  produce root node attributes for XMLConfiguration 
> 
>
> Key: CONFIGURATION-652
> URL: https://issues.apache.org/jira/browse/CONFIGURATION-652
> Project: Commons Configuration
>  Issue Type: Bug
>  Components: Interpolation
>Affects Versions: 2.1.1, 2.2
> Environment: Java 8  on Linux
>Reporter: Claude Warren
>Priority: Major
>  Labels: namespace, xml
> Attachments: Test.java, configuration-652.patch, 
> testChildNamespace.xml, testRootNamespace.xml
>
>
> I have a case where I need to take a Configuration file and write it as an 
> XML document.  The document should have one or more xmlns properties on the 
> root node but the xmlns attributes are not output.



--
This message was sent by Atlassian JIRA
(v7.6.3#76005)