[jira] [Created] (JEXL-294) expression:b == true , when b="abc" then return true

2019-03-27 Thread JIRA
锁战强 created JEXL-294:


 Summary: expression:b == true , when b="abc" then return true
 Key: JEXL-294
 URL: https://issues.apache.org/jira/browse/JEXL-294
 Project: Commons JEXL
  Issue Type: Bug
Affects Versions: 3.1
 Environment: java 8

commons-jexl 3.1
Reporter: 锁战强
 Attachments: image-2019-03-27-18-04-14-420.png

!image-2019-03-27-18-04-14-420.png!



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


[GitHub] [commons-io] col-panic opened a new pull request #76: Refactor io.monitor to support alternativ file entities

2019-03-27 Thread GitBox
col-panic opened a new pull request #76: Refactor io.monitor to support 
alternativ file entities
URL: https://github.com/apache/commons-io/pull/76
 
 
   I want to combine the io.monitor with the https://github.com/hierynomus/smbj 
project, to realize a SMB capable io monitor. In order to achieve this, I have 
to replace certain hard-coded handles like File with the resp. SMBJ handles. 
   
   To this end, I started refactoring the code so that I may realize this 
alternative implementation. Within my IDE i have a prototype of this 
combination (realized within a separate project) that basically works.
   
   My question is: would the commons-io community care for accepting a PR that 
"opens-up" the monitor for alternative implementations?
   
   The PR at hand serves as a basis for discussion.


This is an automated message from the Apache Git Service.
To respond to the message, please log on to GitHub and use the
URL above to go to the specific comment.
 
For queries about this service, please contact Infrastructure at:
us...@infra.apache.org


With regards,
Apache Git Services


[jira] [Updated] (JEXL-294) expression:b == true , when b="abc" then return true

2019-03-27 Thread Henri Biestro (JIRA)


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

Henri Biestro updated JEXL-294:
---
Attachment: (was: image-2019-03-27-18-04-14-420.png)

> expression:b == true , when b="abc" then return true
> 
>
> Key: JEXL-294
> URL: https://issues.apache.org/jira/browse/JEXL-294
> Project: Commons JEXL
>  Issue Type: Bug
>Affects Versions: 3.1
> Environment: java 8
> commons-jexl 3.1
>Reporter: 锁战强
>Priority: Blocker
>
> It seems a bit odd that the expression "abc" == true returns true.
> {code:java}
> 
> @Test
> public void test293() throws Exception {
> final String str = "(b)->{ b == true }";
> JexlContext ctxt = new MapContext();
> JexlEngine jexl = new JexlBuilder().create();
> JexlScript e = jexl.createScript(str);
> Object value = e.execute(ctxt, "abc");
> Assert.assertEquals(true, value); // "abc" == true ??
> }
> {code}



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


[jira] [Updated] (JEXL-294) expression:b == true , when b="abc" then return true

2019-03-27 Thread Henri Biestro (JIRA)


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

Henri Biestro updated JEXL-294:
---
Description: 
It seems a bit odd that the expression "abc" == true returns true.
{code:java}

@Test
public void test293() throws Exception {
final String str = "(b)->{ b == true }";
JexlContext ctxt = new MapContext();
JexlEngine jexl = new JexlBuilder().create();
JexlScript e = jexl.createScript(str);
Object value = e.execute(ctxt, "abc");
Assert.assertEquals(true, value); // "abc" == true ??
}
{code}

  was:!image-2019-03-27-18-04-14-420.png!


> expression:b == true , when b="abc" then return true
> 
>
> Key: JEXL-294
> URL: https://issues.apache.org/jira/browse/JEXL-294
> Project: Commons JEXL
>  Issue Type: Bug
>Affects Versions: 3.1
> Environment: java 8
> commons-jexl 3.1
>Reporter: 锁战强
>Priority: Blocker
>
> It seems a bit odd that the expression "abc" == true returns true.
> {code:java}
> 
> @Test
> public void test293() throws Exception {
> final String str = "(b)->{ b == true }";
> JexlContext ctxt = new MapContext();
> JexlEngine jexl = new JexlBuilder().create();
> JexlScript e = jexl.createScript(str);
> Object value = e.execute(ctxt, "abc");
> Assert.assertEquals(true, value); // "abc" == true ??
> }
> {code}



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


[jira] [Updated] (JEXL-294) expression:b == true , when b="abc" then return true

2019-03-27 Thread Henri Biestro (JIRA)


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

Henri Biestro updated JEXL-294:
---
Assignee: Henri Biestro

> expression:b == true , when b="abc" then return true
> 
>
> Key: JEXL-294
> URL: https://issues.apache.org/jira/browse/JEXL-294
> Project: Commons JEXL
>  Issue Type: Bug
>Affects Versions: 3.1
> Environment: java 8
> commons-jexl 3.1
>Reporter: 锁战强
>Assignee: Henri Biestro
>Priority: Blocker
>
> It seems a bit odd that the expression "abc" == true returns true.
> {code:java}
> 
> @Test
> public void test293() throws Exception {
> final String str = "(b)->{ b == true }";
> JexlContext ctxt = new MapContext();
> JexlEngine jexl = new JexlBuilder().create();
> JexlScript e = jexl.createScript(str);
> Object value = e.execute(ctxt, "abc");
> Assert.assertEquals(true, value); // "abc" == true ??
> }
> {code}



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


[jira] [Updated] (JEXL-294) expression:b == true , when b="abc" then return true

2019-03-27 Thread Henri Biestro (JIRA)


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

Henri Biestro updated JEXL-294:
---
Description: 
It seems a bit odd that the expression "abc" == true returns true.
{code:java}

@Test
public void test294() throws Exception {
final String str = "(b)->{ b == true }";
JexlContext ctxt = new MapContext();
JexlEngine jexl = new JexlBuilder().create();
JexlScript e = jexl.createScript(str);
Object value = e.execute(ctxt, "abc");
Assert.assertEquals(true, value); // "abc" == true ??
}
{code}

  was:
It seems a bit odd that the expression "abc" == true returns true.
{code:java}

@Test
public void test293() throws Exception {
final String str = "(b)->{ b == true }";
JexlContext ctxt = new MapContext();
JexlEngine jexl = new JexlBuilder().create();
JexlScript e = jexl.createScript(str);
Object value = e.execute(ctxt, "abc");
Assert.assertEquals(true, value); // "abc" == true ??
}
{code}


> expression:b == true , when b="abc" then return true
> 
>
> Key: JEXL-294
> URL: https://issues.apache.org/jira/browse/JEXL-294
> Project: Commons JEXL
>  Issue Type: Bug
>Affects Versions: 3.1
> Environment: java 8
> commons-jexl 3.1
>Reporter: 锁战强
>Assignee: Henri Biestro
>Priority: Blocker
>
> It seems a bit odd that the expression "abc" == true returns true.
> {code:java}
> 
> @Test
> public void test294() throws Exception {
> final String str = "(b)->{ b == true }";
> JexlContext ctxt = new MapContext();
> JexlEngine jexl = new JexlBuilder().create();
> JexlScript e = jexl.createScript(str);
> Object value = e.execute(ctxt, "abc");
> Assert.assertEquals(true, value); // "abc" == true ??
> }
> {code}



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


[jira] [Commented] (JEXL-293) leading plus sign not recognized

2019-03-27 Thread Sharon Ben Asher (JIRA)


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

Sharon Ben Asher commented on JEXL-293:
---

Our application accepts String containing user-defined arithmetic expression 
and needs to validate and evaluate it. My QA has opened a bug report saying my 
solution does not accept valid arithmetic expressions that our customers may 
enter. I do not believe that "narrow functional value" is sufficient reason to 
close the ticket, nor would it be acceptable by our Product or Support 
managers. 

Simply put: a valid arithmetic expression that produces an error is a major 
bug. It is not far fetched to say it should be critical. 

 

> leading plus sign not recognized
> 
>
> Key: JEXL-293
> URL: https://issues.apache.org/jira/browse/JEXL-293
> Project: Commons JEXL
>  Issue Type: Bug
>Affects Versions: 3.1
>Reporter: Sharon Ben Asher
>Assignee: Henri Biestro
>Priority: Major
>
> The expression "+2" is not valid ?



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


[jira] [Commented] (POOL-363) Evictor Thread prevents Spring Context shutdown in standalone app

2019-03-27 Thread Gary Gregory (JIRA)


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

Gary Gregory commented on POOL-363:
---

Here is something odd: If all you do is add the spring-context dependency at 
the end of our dependencies, then the build fails with:
{noformat}
[ERROR] Failures:
[ERROR]   
TestAbandonedBasicDataSource>TestBasicDataSource.testMaxConnLifetimeExceeded:701
[ERROR]   
TestAbandonedBasicDataSource>TestBasicDataSource.testPoolCloseCheckedException:467
[ERROR]   TestAbandonedBasicDataSource>TestBasicDataSource.testPoolCloseRTE:490
[ERROR]   TestBasicDataSource.testMaxConnLifetimeExceeded:701
[ERROR]   TestBasicDataSource.testPoolCloseCheckedException:467
[ERROR]   TestBasicDataSource.testPoolCloseRTE:490
[ERROR]   TestBasicDataSourceFactory.testValidateProperties:69 [] expected:<2> 
but was:<0>
[ERROR]   
TestPStmtPoolingBasicDataSource>TestBasicDataSource.testMaxConnLifetimeExceeded:701
[ERROR]   
TestPStmtPoolingBasicDataSource>TestBasicDataSource.testPoolCloseCheckedException:467
[ERROR]   
TestPStmtPoolingBasicDataSource>TestBasicDataSource.testPoolCloseRTE:490
[ERROR]   
TestBasicManagedDataSource>TestBasicDataSource.testMaxConnLifetimeExceeded:701
[ERROR]   
TestBasicManagedDataSource>TestBasicDataSource.testPoolCloseCheckedException:467
[ERROR]   TestBasicManagedDataSource>TestBasicDataSource.testPoolCloseRTE:490
[ERROR]   
TestDataSourceXAConnectionFactory>TestBasicDataSource.testMaxConnLifetimeExceeded:701
[ERROR]   
TestDataSourceXAConnectionFactory>TestBasicDataSource.testPoolCloseCheckedException:467
[ERROR]   
TestDataSourceXAConnectionFactory>TestBasicDataSource.testPoolCloseRTE:490
[INFO]
[ERROR] Tests run: 1416, Failures: 16, Errors: 0, Skipped: 5
{noformat}

> Evictor Thread prevents Spring Context shutdown in standalone app
> -
>
> Key: POOL-363
> URL: https://issues.apache.org/jira/browse/POOL-363
> Project: Commons Pool
>  Issue Type: Bug
>Affects Versions: 2.4.3, 2.5.0, 2.6.0, 2.6.1
> Environment: Java {{1.8.0_92}}
>Reporter: Josh Landin
>Priority: Major
> Attachments: 2019.03.26_screen281.jpg
>
>
> Given a DBCP2 connection pool configured in a Spring Application context with 
> the POOL evictor thread enabled, a standalone main() application hangs on 
> shutdown. Example below:
> Maven pom.xml:
> {code:xml}
>   
> 
>   org.apache.commons
>   commons-dbcp2
>   2.6.0
> 
> 
>   mysql
>   mysql-connector-java
>   8.0.15
> 
> 
>   org.springframework
>   spring-context
>   5.1.5.RELEASE
> 
>   
> {code}
> MainTest.java:
> {code:java}
> import java.sql.Connection;
> import java.sql.ResultSet;
> import java.sql.SQLException;
> import java.sql.Statement;
> import javax.sql.DataSource;
> import org.apache.commons.dbcp2.BasicDataSource;
> import 
> org.springframework.context.annotation.AnnotationConfigApplicationContext;
> import org.springframework.context.annotation.Bean;
> import org.springframework.context.annotation.Configuration;
> public class MainTest
> {
>   @Configuration
>   public static class Config 
>   {
> @Bean
> public DataSource getBasicDataSource()
> {
>   BasicDataSource d = new BasicDataSource();
>   d.setUrl("jdbc:mysql://localhost:3306/anydb");
>   d.setUsername("myuser");
>   d.setPassword("mypass");
>   d.setTimeBetweenEvictionRunsMillis(1000); // Turn on Evictor Thread.
>   return d;
> }
>   }
>   public static void main(String[] args)
>   {
> AnnotationConfigApplicationContext ctx = new 
> AnnotationConfigApplicationContext(Config.class);
> ctx.registerShutdownHook(); // Ensures context.close() on JVM shutdown.
> 
> try(
> Connection conn = ctx.getBean(BasicDataSource.class).getConnection(); 
> Statement stmt = conn.createStatement();
> ResultSet result = stmt.executeQuery("SELECT 1");
> )
> {
>   int records = result.last() ? result.getRow() : 0;
>   System.out.println("Records: "+records);
> }
> catch(SQLException e)
> {
>   e.printStackTrace();
> }
> System.out.println("End.");
>   }
> }
> {code}
> The issue is not present when turning off the eviction thread by setting 
> {{timeBetweenEvictionRunsMillis}} to {{-1}}.
> Jconsole thread summary attached for reference.



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


[jira] [Commented] (JEXL-293) leading plus sign not recognized

2019-03-27 Thread Henri Biestro (JIRA)


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

Henri Biestro commented on JEXL-293:


Thank you for clarifying why this is an issue in your environment.
Are you in a position to use snapshot versions ? If a Jexl 3.2-SNAPSHOT jar was 
produced, would you be able to use it ?
PS: Do you need to be angry or right or do you want help ?

> leading plus sign not recognized
> 
>
> Key: JEXL-293
> URL: https://issues.apache.org/jira/browse/JEXL-293
> Project: Commons JEXL
>  Issue Type: Bug
>Affects Versions: 3.1
>Reporter: Sharon Ben Asher
>Assignee: Henri Biestro
>Priority: Major
>
> The expression "+2" is not valid ?



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


[jira] [Comment Edited] (JEXL-293) leading plus sign not recognized

2019-03-27 Thread Sharon Ben Asher (JIRA)


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

Sharon Ben Asher edited comment on JEXL-293 at 3/27/19 2:11 PM:


Our application accepts String containing user-defined arithmetic expression 
and needs to validate and evaluate it. My QA has opened a bug report saying my 
solution does not accept valid arithmetic expressions that our customers may 
enter. I do not believe that "narrow functional value" is sufficient reason to 
close the ticket, nor would it be acceptable by our Product or Support 
managers. 

Simply put: a valid arithmetic expression that produces an error is a major 
bug. It is not far fetched to say it should be critical. 

PS, Although the Language Elements page mentions only the unary minus operator, 
*it does not explicitly specifies that unary plus is invalid*. Something that 
devs may easily overlook when evaluating whether or not to use this library (as 
I have done)

 


was (Author: sharonbn):
Our application accepts String containing user-defined arithmetic expression 
and needs to validate and evaluate it. My QA has opened a bug report saying my 
solution does not accept valid arithmetic expressions that our customers may 
enter. I do not believe that "narrow functional value" is sufficient reason to 
close the ticket, nor would it be acceptable by our Product or Support 
managers. 

Simply put: a valid arithmetic expression that produces an error is a major 
bug. It is not far fetched to say it should be critical. 

 

> leading plus sign not recognized
> 
>
> Key: JEXL-293
> URL: https://issues.apache.org/jira/browse/JEXL-293
> Project: Commons JEXL
>  Issue Type: Bug
>Affects Versions: 3.1
>Reporter: Sharon Ben Asher
>Assignee: Henri Biestro
>Priority: Major
>
> The expression "+2" is not valid ?



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


[jira] [Commented] (JEXL-294) expression:b == true , when b="abc" then return true

2019-03-27 Thread Henri Biestro (JIRA)


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

Henri Biestro commented on JEXL-294:


It may seem odd but the explanation resides in the logic statement 'everything 
that is not false is true'.

The values 0, NaN, null, false, the empty-string and the "false" string are 
considered false in the default JEXL arithmetic, any other value is considered 
true. The default 'equals' operator in presence of one boolean argument will 
coerce the second one to a boolean also. The implication is thus that "abc" is 
our example is coerced to boolean; since that string is neither empty nor 
"false", it is true. And true == true.

If you need a different behaviour, I'd recommend implementing your own 
JexlArithmetic, one that would not coerce boolean arguments.
{code:java}
public static class Arithmetic294 extends JexlArithmetic {
/** Ctor. */
public Arithmetic294(boolean f) {
super(f);
}

@Override
public boolean equals(Object left, Object right) {
if (left == right) {
return true;
} else if (left == null || right == null) {
return false;
} else {
return compare(left, right, "==") == 0;
}
}
}

@Test
public void test294b() throws Exception {
final String str = "(b)->{ b == true }";
JexlContext ctxt = new MapContext();
JexlEngine jexl = new JexlBuilder().arithmetic(new 
Arithmetic294(true)).create();
JexlScript e = jexl.createScript(str);
Object value = e.execute(ctxt, "abc");
Assert.assertEquals(false, value); 
value = e.execute(ctxt, true);
Assert.assertEquals(true, value); 
}
{code}
 

 

 

> expression:b == true , when b="abc" then return true
> 
>
> Key: JEXL-294
> URL: https://issues.apache.org/jira/browse/JEXL-294
> Project: Commons JEXL
>  Issue Type: Bug
>Affects Versions: 3.1
> Environment: java 8
> commons-jexl 3.1
>Reporter: 锁战强
>Assignee: Henri Biestro
>Priority: Blocker
>
> It seems a bit odd that the expression "abc" == true returns true.
> {code:java}
> 
> @Test
> public void test294() throws Exception {
> final String str = "(b)->{ b == true }";
> JexlContext ctxt = new MapContext();
> JexlEngine jexl = new JexlBuilder().create();
> JexlScript e = jexl.createScript(str);
> Object value = e.execute(ctxt, "abc");
> Assert.assertEquals(true, value); // "abc" == true ??
> }
> {code}



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


[jira] [Comment Edited] (JEXL-293) leading plus sign not recognized

2019-03-27 Thread Sharon Ben Asher (JIRA)


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

Sharon Ben Asher edited comment on JEXL-293 at 3/27/19 2:48 PM:


I am OK to use snapshot version.
 I am not angry. I did not understand why I need to explain something that is 
obvious in my eyes. 

I apologize if my choice of words was perceived abrasive.


was (Author: sharonbn):
I am OK to use snapshot version.
I am not angry. I did not understand why I need to explain something that is 
obvious in my eyes. 

> leading plus sign not recognized
> 
>
> Key: JEXL-293
> URL: https://issues.apache.org/jira/browse/JEXL-293
> Project: Commons JEXL
>  Issue Type: Bug
>Affects Versions: 3.1
>Reporter: Sharon Ben Asher
>Assignee: Henri Biestro
>Priority: Major
>
> The expression "+2" is not valid ?



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


[jira] [Comment Edited] (JEXL-293) leading plus sign not recognized

2019-03-27 Thread Sharon Ben Asher (JIRA)


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

Sharon Ben Asher edited comment on JEXL-293 at 3/27/19 2:48 PM:


I am OK to use snapshot version.
 I am not angry. I did not understand why I need to explain something that is 
obvious in my eyes. 

I apologize if my choice of words was perceived as abrasive.


was (Author: sharonbn):
I am OK to use snapshot version.
 I am not angry. I did not understand why I need to explain something that is 
obvious in my eyes. 

I apologize if my choice of words was perceived abrasive.

> leading plus sign not recognized
> 
>
> Key: JEXL-293
> URL: https://issues.apache.org/jira/browse/JEXL-293
> Project: Commons JEXL
>  Issue Type: Bug
>Affects Versions: 3.1
>Reporter: Sharon Ben Asher
>Assignee: Henri Biestro
>Priority: Major
>
> The expression "+2" is not valid ?



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


[jira] [Updated] (JEXL-293) leading plus sign not recognized

2019-03-27 Thread Henri Biestro (JIRA)


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

Henri Biestro updated JEXL-293:
---
Assignee: Henri Biestro

> leading plus sign not recognized
> 
>
> Key: JEXL-293
> URL: https://issues.apache.org/jira/browse/JEXL-293
> Project: Commons JEXL
>  Issue Type: Bug
>Affects Versions: 3.1
>Reporter: Sharon Ben Asher
>Assignee: Henri Biestro
>Priority: Major
>
> The expression "+2" is not valid ?



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


[jira] [Commented] (JEXL-293) leading plus sign not recognized

2019-03-27 Thread Henri Biestro (JIRA)


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

Henri Biestro commented on JEXL-293:


Indeed, it is not syntactically correct; there is a unary minus operator, no 
unary plus operator.
In Java, unary plus promotes a byte, char or short operand to int; note that 
this is not a Math.abs(...) shortcut btw.
Since number literals are already integer in Jexl, functional value seems 
narrow.
Care to explain why this is a major bug in your case ?

> leading plus sign not recognized
> 
>
> Key: JEXL-293
> URL: https://issues.apache.org/jira/browse/JEXL-293
> Project: Commons JEXL
>  Issue Type: Bug
>Affects Versions: 3.1
>Reporter: Sharon Ben Asher
>Assignee: Henri Biestro
>Priority: Major
>
> The expression "+2" is not valid ?



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


[jira] [Commented] (JEXL-293) leading plus sign not recognized

2019-03-27 Thread Henri Biestro (JIRA)


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

Henri Biestro commented on JEXL-293:


JEXL is 8+ years old, lack of unary plus has not been an issue till yesterday. 
Pardon my curiosity.

Based on your reaction, I'd encourage your PM/PO/QA and you to check that the 
rest of the JEXL syntax - and JEXL itself - is appropriate to your project. 
There might be many other unmet expectations and behaviour discrepancies from 
the specification of your own expression language.


> leading plus sign not recognized
> 
>
> Key: JEXL-293
> URL: https://issues.apache.org/jira/browse/JEXL-293
> Project: Commons JEXL
>  Issue Type: Bug
>Affects Versions: 3.1
>Reporter: Sharon Ben Asher
>Assignee: Henri Biestro
>Priority: Major
>
> The expression "+2" is not valid ?



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


[jira] [Commented] (JEXL-295) Add unary plus operator

2019-03-27 Thread Henri Biestro (JIRA)


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

Henri Biestro commented on JEXL-295:


Changeset: 1f00432517aa46bdf0197e1e85a007f4076c01ed
Author:henrib 
Date:  2019-03-27 18:52
Message:   JEXL-295: add unary plus support and arithmetic positivize method

> Add unary plus operator
> ---
>
> Key: JEXL-295
> URL: https://issues.apache.org/jira/browse/JEXL-295
> Project: Commons JEXL
>  Issue Type: New Feature
>Affects Versions: 3.1
>Reporter: Henri Biestro
>Assignee: Henri Biestro
>Priority: Major
> Fix For: 3.2
>
>
> WHAT
> Introduce a new operator, the unary plus as in '+4' or '+b' expressions. JEXL 
> arithmetic already allows using a unary minus operator (the negate operation) 
> so there is logic in having the counterpart.
> The proposed default behaviour would be to:
> - call the 'Math.abs(...)' method for numbers
> - return true for boolean 
> - could uppercase strings ? (should '-' lowercase strings ??)
> HOW
> - Follow the unary minus syntax and construct in the .jjt / ASTUnaryPlus / 
> ParserVisitor
> - Implement Interpreter, Debugger
> - Implement abs in JexlArithmetic



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


[jira] [Commented] (POOL-363) Evictor Thread prevents Spring Context shutdown in standalone app

2019-03-27 Thread Josh Landin (JIRA)


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

Josh Landin commented on POOL-363:
--

[~garydgregory] To help narrow the scope, reverting this change in 
{{org.apache.commons.pool2.impl.EvictionTimer}} fixes the issue:
 
[https://github.com/apache/commons-pool/commit/4a20cdca923bd342360f821d7020538e985d9ec2#diff-38e254894b87bdf9a1758778c7ffd50f]

Note that there is a typo in the commit message referencing _POOL-351_, but 
should be POOL-315 instead.

> Evictor Thread prevents Spring Context shutdown in standalone app
> -
>
> Key: POOL-363
> URL: https://issues.apache.org/jira/browse/POOL-363
> Project: Commons Pool
>  Issue Type: Bug
>Affects Versions: 2.4.3, 2.5.0, 2.6.0, 2.6.1
> Environment: Java {{1.8.0_92}}
>Reporter: Josh Landin
>Priority: Major
> Attachments: 2019.03.26_screen281.jpg
>
>
> Given a DBCP2 connection pool configured in a Spring Application context with 
> the POOL evictor thread enabled, a standalone main() application hangs on 
> shutdown. Example below:
> Maven pom.xml:
> {code:xml}
>   
> 
>   org.apache.commons
>   commons-dbcp2
>   2.6.0
> 
> 
>   mysql
>   mysql-connector-java
>   8.0.15
> 
> 
>   org.springframework
>   spring-context
>   5.1.5.RELEASE
> 
>   
> {code}
> MainTest.java:
> {code:java}
> import java.sql.Connection;
> import java.sql.ResultSet;
> import java.sql.SQLException;
> import java.sql.Statement;
> import javax.sql.DataSource;
> import org.apache.commons.dbcp2.BasicDataSource;
> import 
> org.springframework.context.annotation.AnnotationConfigApplicationContext;
> import org.springframework.context.annotation.Bean;
> import org.springframework.context.annotation.Configuration;
> public class MainTest
> {
>   @Configuration
>   public static class Config 
>   {
> @Bean
> public DataSource getBasicDataSource()
> {
>   BasicDataSource d = new BasicDataSource();
>   d.setUrl("jdbc:mysql://localhost:3306/anydb");
>   d.setUsername("myuser");
>   d.setPassword("mypass");
>   d.setTimeBetweenEvictionRunsMillis(1000); // Turn on Evictor Thread.
>   return d;
> }
>   }
>   public static void main(String[] args)
>   {
> AnnotationConfigApplicationContext ctx = new 
> AnnotationConfigApplicationContext(Config.class);
> ctx.registerShutdownHook(); // Ensures context.close() on JVM shutdown.
> 
> try(
> Connection conn = ctx.getBean(BasicDataSource.class).getConnection(); 
> Statement stmt = conn.createStatement();
> ResultSet result = stmt.executeQuery("SELECT 1");
> )
> {
>   int records = result.last() ? result.getRow() : 0;
>   System.out.println("Records: "+records);
> }
> catch(SQLException e)
> {
>   e.printStackTrace();
> }
> System.out.println("End.");
>   }
> }
> {code}
> The issue is not present when turning off the eviction thread by setting 
> {{timeBetweenEvictionRunsMillis}} to {{-1}}.
> Jconsole thread summary attached for reference.



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


[jira] [Commented] (STATISTICS-7) Stream-based Java statistical processing

2019-03-27 Thread Eric Barnhill (JIRA)


[ 
https://issues.apache.org/jira/browse/STATISTICS-7?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16803070#comment-16803070
 ] 

Eric Barnhill commented on STATISTICS-7:


[~Salman] First of all I'll be delighted to read over the proposal, this is 
happening right now in some other projects.

Seems to me time frame depends entirely on the skill set of the applicant. But 
I would set aside some time for each of the following in the proposal:
 * Project design – choose which stat functions you are interested in developing
 * Dependency analysis – what other classes do the stat functions currently 
depend on in commons-math and what is the purpose of those functions? What 
changes need to be made in order to create a standalone statistical component? 
For example, is the method depending on abstract classes, exception classes, 
formatting classes? Are these dependencies necessary or can they be 
restructured to be more stand alone? Whatever decision creates the best 
architecture is best of course
 * New component architecture - what will be the class hiearchy of the 
redesigned component?
 * Class design - do I want the user to create an object instance, or call a 
static method, to use this functionality? Do I want some enums to handle 
parameters of various kinds? What kinds of inputs should it take? How do I 
handle different data types? What are the outputs?
 * Unit test design - creating a property-driven unit testing scheme
 * Algorithm Validation – is there code in other languages that I can use to 
validate test inputs?
 * Documentation - what doc will go with each class and method? What addition 
doc should be in the user guides? Ideally the project could conclude with a 
couple of tutorials implementing working examples

> Stream-based Java statistical processing
> 
>
> Key: STATISTICS-7
> URL: https://issues.apache.org/jira/browse/STATISTICS-7
> Project: Apache Commons Statistics
>  Issue Type: New Feature
>Reporter: Eric Barnhill
>Priority: Major
>  Labels: GSoC2019, gsoc2019, statistics, streams
>
> The new component aims to be a library of commons statistics functions 
> synchronized with the latest developments in the Java language, in particular 
> Java's functional programming syntax.
> The library will make commonly used statistical functions available to an end 
> user through a simple grammar comparable to commons-math-statistics or 
> scikit-learn, while under the hood will implement Java's mapping, streaming, 
> and other producer and consumer functions to ensure the statistical methods 
> run optimally in new Java implementations.
> Developers working on the project will have the opportunity to demonstrate 
> Java programming, functional programming, algorithm design, and data science 
> skills and receive authorship on a commons project that is likely to be 
> widely used.
> The ideal contributor will also be able to help with important architectural 
> decision making. The old source of these libraries, commons-math, grew too 
> large, hierarchically complex and interdependent for the commons mission. The 
> developers on this project need to make architectural choices that will 
> enable the statiscal code to be lightweight and reusable, with a minimum of 
> outside dependencies while avoiding redundancy.



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


[jira] [Updated] (JEXL-295) Add unary plus operator

2019-03-27 Thread Henri Biestro (JIRA)


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

Henri Biestro updated JEXL-295:
---
Description: 
WHAT
Introduce a new operator, the unary plus as in '+4' or '+b' expressions. JEXL 
arithmetic already allows using a unary minus operator (the negate operation) 
so there is logic in having the counterpart.

The proposed default behaviour would be to:
- call the 'Math.abs(...)' method for numbers
- return true for boolean 
- could uppercase strings ? (should '-' lowercase strings ??)


HOW
- Follow the unary minus syntax and construct in the .jjt / ASTUnaryPlus / 
ParserVisitor
- Implement Interpreter, Debugger
- Implement abs in JexlArithmetic

  was:
WHAT
Introduce a new operator, the unary plus as in '+4' or '+b' expressions. The 
proposed default behaviour would be to:
- call the 'Math.abs(...)' method for numbers
- return true for boolean 
- could uppercase strings ? (should '-' lowercase strings ??)
JEXL arithmetic already allows using a unary minus operator (the negate 
operation) so there is logic in having the counterpart.

HOW
- Follow the unary minus syntax and construct in the .jjt / ASTUnaryPlus / 
ParserVisitor
- Implement Interpreter, Debugger
- Implement abs in JexlArithmetic


> Add unary plus operator
> ---
>
> Key: JEXL-295
> URL: https://issues.apache.org/jira/browse/JEXL-295
> Project: Commons JEXL
>  Issue Type: New Feature
>Affects Versions: 3.1
>Reporter: Henri Biestro
>Assignee: Henri Biestro
>Priority: Major
> Fix For: 3.2
>
>
> WHAT
> Introduce a new operator, the unary plus as in '+4' or '+b' expressions. JEXL 
> arithmetic already allows using a unary minus operator (the negate operation) 
> so there is logic in having the counterpart.
> The proposed default behaviour would be to:
> - call the 'Math.abs(...)' method for numbers
> - return true for boolean 
> - could uppercase strings ? (should '-' lowercase strings ??)
> HOW
> - Follow the unary minus syntax and construct in the .jjt / ASTUnaryPlus / 
> ParserVisitor
> - Implement Interpreter, Debugger
> - Implement abs in JexlArithmetic



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


[jira] [Created] (JEXL-295) Add unary plus operator

2019-03-27 Thread Henri Biestro (JIRA)
Henri Biestro created JEXL-295:
--

 Summary: Add unary plus operator
 Key: JEXL-295
 URL: https://issues.apache.org/jira/browse/JEXL-295
 Project: Commons JEXL
  Issue Type: New Feature
Affects Versions: 3.1
Reporter: Henri Biestro
Assignee: Henri Biestro
 Fix For: 3.2


WHAT
Introduce a new operator, the unary plus as in '+4' or '+b' expressions. The 
proposed default behaviour would be to:
- call the 'Math.abs(...)' method for numbers
- return true for boolean 
- could uppercase strings ? (should '-' lowercase strings ??)
JEXL arithmetic already allows using a unary minus operator (the negate 
operation) so there is logic in having the counterpart.

HOW
- Follow the unary minus syntax and construct in the .jjt / ASTUnaryPlus / 
ParserVisitor
- Implement Interpreter, Debugger
- Implement abs in JexlArithmetic



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


[GitHub] [commons-pool] joshlandin opened a new pull request #20: Fix for POOL-363

2019-03-27 Thread GitBox
joshlandin opened a new pull request #20: Fix for POOL-363
URL: https://github.com/apache/commons-pool/pull/20
 
 
   Updated evictor thread to be a daemon, thus no longer blocking
   application hooks (added via Runtime.addShutdownHook) and causing the VM
   to hang on shutdown. For example, stand-alone applications using the
   Spring Framework.


This is an automated message from the Apache Git Service.
To respond to the message, please log on to GitHub and use the
URL above to go to the specific comment.
 
For queries about this service, please contact Infrastructure at:
us...@infra.apache.org


With regards,
Apache Git Services


[jira] [Comment Edited] (POOL-363) Evictor Thread prevents Spring Context shutdown in standalone app

2019-03-27 Thread Josh Landin (JIRA)


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

Josh Landin edited comment on POOL-363 at 3/27/19 8:58 PM:
---

PR - https://github.com/apache/commons-pool/pull/20
As described 
[here|https://docs.oracle.com/javase/8/docs/api/java/lang/Runtime.html#addShutdownHook-java.lang.Thread-],
 shutdown hooks cannot be started until all non-daemon threads have exited. In 
the case of commons-pool, historically the Evictor thread is not a daemon and 
does not exit while the object pool is open. This results in a deadlock in 
stand-alone application environments where DBCP is configured and managed by a 
Spring context, since the {{BasicDataSource}} is only closed during the Spring 
context shutdown hook. Changing the Evictor thread to be a daemon allows the 
Runtime shutdown process to proceed normally.


was (Author: jlandin):
PR - https://github.com/apache/commons-pool/pull/20
As described 
[here|https://docs.oracle.com/javase/8/docs/api/java/lang/Runtime.html#addShutdownHook-java.lang.Thread-],
 shutdown hooks cannot be started until all non-daemon threads have exited. In 
the case of commons-pool, the Evictor thread does not exit while the object 
pool is open. This results in a deadlock in stand-alone application 
environments where DBCP is configured and managed by a Spring context, since 
the {{BasicDataSource}} is only closed during the Spring context shutdown hook. 
Changing the Evictor thread to be a daemon allows the Runtime shutdown process 
to proceed normally.

> Evictor Thread prevents Spring Context shutdown in standalone app
> -
>
> Key: POOL-363
> URL: https://issues.apache.org/jira/browse/POOL-363
> Project: Commons Pool
>  Issue Type: Bug
>Affects Versions: 2.4.3, 2.5.0, 2.6.0, 2.6.1
> Environment: Java {{1.8.0_92}}
>Reporter: Josh Landin
>Priority: Major
> Attachments: 2019.03.26_screen281.jpg
>
>  Time Spent: 10m
>  Remaining Estimate: 0h
>
> Given a DBCP2 connection pool configured in a Spring Application context with 
> the POOL evictor thread enabled, a standalone main() application hangs on 
> shutdown. Example below:
> Maven pom.xml:
> {code:xml}
>   
> 
>   org.apache.commons
>   commons-dbcp2
>   2.6.0
> 
> 
>   mysql
>   mysql-connector-java
>   8.0.15
> 
> 
>   org.springframework
>   spring-context
>   5.1.5.RELEASE
> 
>   
> {code}
> MainTest.java:
> {code:java}
> import java.sql.Connection;
> import java.sql.ResultSet;
> import java.sql.SQLException;
> import java.sql.Statement;
> import javax.sql.DataSource;
> import org.apache.commons.dbcp2.BasicDataSource;
> import 
> org.springframework.context.annotation.AnnotationConfigApplicationContext;
> import org.springframework.context.annotation.Bean;
> import org.springframework.context.annotation.Configuration;
> public class MainTest
> {
>   @Configuration
>   public static class Config 
>   {
> @Bean
> public DataSource getBasicDataSource()
> {
>   BasicDataSource d = new BasicDataSource();
>   d.setUrl("jdbc:mysql://localhost:3306/anydb");
>   d.setUsername("myuser");
>   d.setPassword("mypass");
>   d.setTimeBetweenEvictionRunsMillis(1000); // Turn on Evictor Thread.
>   return d;
> }
>   }
>   public static void main(String[] args)
>   {
> AnnotationConfigApplicationContext ctx = new 
> AnnotationConfigApplicationContext(Config.class);
> ctx.registerShutdownHook(); // Ensures context.close() on JVM shutdown.
> 
> try(
> Connection conn = ctx.getBean(BasicDataSource.class).getConnection(); 
> Statement stmt = conn.createStatement();
> ResultSet result = stmt.executeQuery("SELECT 1");
> )
> {
>   int records = result.last() ? result.getRow() : 0;
>   System.out.println("Records: "+records);
> }
> catch(SQLException e)
> {
>   e.printStackTrace();
> }
> System.out.println("End.");
>   }
> }
> {code}
> The issue is not present when turning off the eviction thread by setting 
> {{timeBetweenEvictionRunsMillis}} to {{-1}}.
> Jconsole thread summary attached for reference.



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


[jira] [Commented] (POOL-363) Evictor Thread prevents Spring Context shutdown in standalone app

2019-03-27 Thread Josh Landin (JIRA)


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

Josh Landin commented on POOL-363:
--

Found the issue, I'll submit a PR.

> Evictor Thread prevents Spring Context shutdown in standalone app
> -
>
> Key: POOL-363
> URL: https://issues.apache.org/jira/browse/POOL-363
> Project: Commons Pool
>  Issue Type: Bug
>Affects Versions: 2.4.3, 2.5.0, 2.6.0, 2.6.1
> Environment: Java {{1.8.0_92}}
>Reporter: Josh Landin
>Priority: Major
> Attachments: 2019.03.26_screen281.jpg
>
>
> Given a DBCP2 connection pool configured in a Spring Application context with 
> the POOL evictor thread enabled, a standalone main() application hangs on 
> shutdown. Example below:
> Maven pom.xml:
> {code:xml}
>   
> 
>   org.apache.commons
>   commons-dbcp2
>   2.6.0
> 
> 
>   mysql
>   mysql-connector-java
>   8.0.15
> 
> 
>   org.springframework
>   spring-context
>   5.1.5.RELEASE
> 
>   
> {code}
> MainTest.java:
> {code:java}
> import java.sql.Connection;
> import java.sql.ResultSet;
> import java.sql.SQLException;
> import java.sql.Statement;
> import javax.sql.DataSource;
> import org.apache.commons.dbcp2.BasicDataSource;
> import 
> org.springframework.context.annotation.AnnotationConfigApplicationContext;
> import org.springframework.context.annotation.Bean;
> import org.springframework.context.annotation.Configuration;
> public class MainTest
> {
>   @Configuration
>   public static class Config 
>   {
> @Bean
> public DataSource getBasicDataSource()
> {
>   BasicDataSource d = new BasicDataSource();
>   d.setUrl("jdbc:mysql://localhost:3306/anydb");
>   d.setUsername("myuser");
>   d.setPassword("mypass");
>   d.setTimeBetweenEvictionRunsMillis(1000); // Turn on Evictor Thread.
>   return d;
> }
>   }
>   public static void main(String[] args)
>   {
> AnnotationConfigApplicationContext ctx = new 
> AnnotationConfigApplicationContext(Config.class);
> ctx.registerShutdownHook(); // Ensures context.close() on JVM shutdown.
> 
> try(
> Connection conn = ctx.getBean(BasicDataSource.class).getConnection(); 
> Statement stmt = conn.createStatement();
> ResultSet result = stmt.executeQuery("SELECT 1");
> )
> {
>   int records = result.last() ? result.getRow() : 0;
>   System.out.println("Records: "+records);
> }
> catch(SQLException e)
> {
>   e.printStackTrace();
> }
> System.out.println("End.");
>   }
> }
> {code}
> The issue is not present when turning off the eviction thread by setting 
> {{timeBetweenEvictionRunsMillis}} to {{-1}}.
> Jconsole thread summary attached for reference.



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


[jira] [Commented] (POOL-363) Evictor Thread prevents Spring Context shutdown in standalone app

2019-03-27 Thread Josh Landin (JIRA)


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

Josh Landin commented on POOL-363:
--

PR - https://github.com/apache/commons-pool/pull/20
As described 
[here|https://docs.oracle.com/javase/8/docs/api/java/lang/Runtime.html#addShutdownHook-java.lang.Thread-],
 shutdown hooks cannot be started until all non-daemon threads have exited. In 
the case of commons-pool, the Evictor thread does not exit while the object 
pool is open. This results in a deadlock in stand-alone application 
environments where DBCP is configured and managed by a Spring context, since 
the {{BasicDataSource}} is only closed during the Spring context shutdown hook. 
Changing the Evictor thread to be a daemon allows the Runtime shutdown process 
to proceed normally.

> Evictor Thread prevents Spring Context shutdown in standalone app
> -
>
> Key: POOL-363
> URL: https://issues.apache.org/jira/browse/POOL-363
> Project: Commons Pool
>  Issue Type: Bug
>Affects Versions: 2.4.3, 2.5.0, 2.6.0, 2.6.1
> Environment: Java {{1.8.0_92}}
>Reporter: Josh Landin
>Priority: Major
> Attachments: 2019.03.26_screen281.jpg
>
>  Time Spent: 10m
>  Remaining Estimate: 0h
>
> Given a DBCP2 connection pool configured in a Spring Application context with 
> the POOL evictor thread enabled, a standalone main() application hangs on 
> shutdown. Example below:
> Maven pom.xml:
> {code:xml}
>   
> 
>   org.apache.commons
>   commons-dbcp2
>   2.6.0
> 
> 
>   mysql
>   mysql-connector-java
>   8.0.15
> 
> 
>   org.springframework
>   spring-context
>   5.1.5.RELEASE
> 
>   
> {code}
> MainTest.java:
> {code:java}
> import java.sql.Connection;
> import java.sql.ResultSet;
> import java.sql.SQLException;
> import java.sql.Statement;
> import javax.sql.DataSource;
> import org.apache.commons.dbcp2.BasicDataSource;
> import 
> org.springframework.context.annotation.AnnotationConfigApplicationContext;
> import org.springframework.context.annotation.Bean;
> import org.springframework.context.annotation.Configuration;
> public class MainTest
> {
>   @Configuration
>   public static class Config 
>   {
> @Bean
> public DataSource getBasicDataSource()
> {
>   BasicDataSource d = new BasicDataSource();
>   d.setUrl("jdbc:mysql://localhost:3306/anydb");
>   d.setUsername("myuser");
>   d.setPassword("mypass");
>   d.setTimeBetweenEvictionRunsMillis(1000); // Turn on Evictor Thread.
>   return d;
> }
>   }
>   public static void main(String[] args)
>   {
> AnnotationConfigApplicationContext ctx = new 
> AnnotationConfigApplicationContext(Config.class);
> ctx.registerShutdownHook(); // Ensures context.close() on JVM shutdown.
> 
> try(
> Connection conn = ctx.getBean(BasicDataSource.class).getConnection(); 
> Statement stmt = conn.createStatement();
> ResultSet result = stmt.executeQuery("SELECT 1");
> )
> {
>   int records = result.last() ? result.getRow() : 0;
>   System.out.println("Records: "+records);
> }
> catch(SQLException e)
> {
>   e.printStackTrace();
> }
> System.out.println("End.");
>   }
> }
> {code}
> The issue is not present when turning off the eviction thread by setting 
> {{timeBetweenEvictionRunsMillis}} to {{-1}}.
> Jconsole thread summary attached for reference.



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


[jira] [Work logged] (POOL-363) Evictor Thread prevents Spring Context shutdown in standalone app

2019-03-27 Thread ASF GitHub Bot (JIRA)


 [ 
https://issues.apache.org/jira/browse/POOL-363?focusedWorklogId=219558=com.atlassian.jira.plugin.system.issuetabpanels:worklog-tabpanel#worklog-219558
 ]

ASF GitHub Bot logged work on POOL-363:
---

Author: ASF GitHub Bot
Created on: 27/Mar/19 19:50
Start Date: 27/Mar/19 19:50
Worklog Time Spent: 10m 
  Work Description: joshlandin commented on pull request #20: Fix for 
POOL-363
URL: https://github.com/apache/commons-pool/pull/20
 
 
   Updated evictor thread to be a daemon, thus no longer blocking
   application hooks (added via Runtime.addShutdownHook) and causing the VM
   to hang on shutdown. For example, stand-alone applications using the
   Spring Framework.
 

This is an automated message from the Apache Git Service.
To respond to the message, please log on to GitHub and use the
URL above to go to the specific comment.
 
For queries about this service, please contact Infrastructure at:
us...@infra.apache.org


Issue Time Tracking
---

Worklog Id: (was: 219558)
Time Spent: 10m
Remaining Estimate: 0h

> Evictor Thread prevents Spring Context shutdown in standalone app
> -
>
> Key: POOL-363
> URL: https://issues.apache.org/jira/browse/POOL-363
> Project: Commons Pool
>  Issue Type: Bug
>Affects Versions: 2.4.3, 2.5.0, 2.6.0, 2.6.1
> Environment: Java {{1.8.0_92}}
>Reporter: Josh Landin
>Priority: Major
> Attachments: 2019.03.26_screen281.jpg
>
>  Time Spent: 10m
>  Remaining Estimate: 0h
>
> Given a DBCP2 connection pool configured in a Spring Application context with 
> the POOL evictor thread enabled, a standalone main() application hangs on 
> shutdown. Example below:
> Maven pom.xml:
> {code:xml}
>   
> 
>   org.apache.commons
>   commons-dbcp2
>   2.6.0
> 
> 
>   mysql
>   mysql-connector-java
>   8.0.15
> 
> 
>   org.springframework
>   spring-context
>   5.1.5.RELEASE
> 
>   
> {code}
> MainTest.java:
> {code:java}
> import java.sql.Connection;
> import java.sql.ResultSet;
> import java.sql.SQLException;
> import java.sql.Statement;
> import javax.sql.DataSource;
> import org.apache.commons.dbcp2.BasicDataSource;
> import 
> org.springframework.context.annotation.AnnotationConfigApplicationContext;
> import org.springframework.context.annotation.Bean;
> import org.springframework.context.annotation.Configuration;
> public class MainTest
> {
>   @Configuration
>   public static class Config 
>   {
> @Bean
> public DataSource getBasicDataSource()
> {
>   BasicDataSource d = new BasicDataSource();
>   d.setUrl("jdbc:mysql://localhost:3306/anydb");
>   d.setUsername("myuser");
>   d.setPassword("mypass");
>   d.setTimeBetweenEvictionRunsMillis(1000); // Turn on Evictor Thread.
>   return d;
> }
>   }
>   public static void main(String[] args)
>   {
> AnnotationConfigApplicationContext ctx = new 
> AnnotationConfigApplicationContext(Config.class);
> ctx.registerShutdownHook(); // Ensures context.close() on JVM shutdown.
> 
> try(
> Connection conn = ctx.getBean(BasicDataSource.class).getConnection(); 
> Statement stmt = conn.createStatement();
> ResultSet result = stmt.executeQuery("SELECT 1");
> )
> {
>   int records = result.last() ? result.getRow() : 0;
>   System.out.println("Records: "+records);
> }
> catch(SQLException e)
> {
>   e.printStackTrace();
> }
> System.out.println("End.");
>   }
> }
> {code}
> The issue is not present when turning off the eviction thread by setting 
> {{timeBetweenEvictionRunsMillis}} to {{-1}}.
> Jconsole thread summary attached for reference.



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


[jira] [Comment Edited] (POOL-363) Evictor Thread prevents Spring Context shutdown in standalone app

2019-03-27 Thread Josh Landin (JIRA)


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

Josh Landin edited comment on POOL-363 at 3/27/19 8:59 PM:
---

PR - https://github.com/apache/commons-pool/pull/20
As described 
[here|https://docs.oracle.com/javase/8/docs/api/java/lang/Runtime.html#addShutdownHook-java.lang.Thread-],
 shutdown hooks cannot be started until all non-daemon threads have exited. In 
the case of commons-pool, historically the Evictor thread is not a daemon and 
does not exit while the object pool is open. This results in a deadlock in 
stand-alone application environments where DBCP is configured and managed by a 
Spring context, since the {{BasicDataSource}} is only closed during the Spring 
context shutdown hook. Changing the Evictor thread to be a daemon allows the 
Runtime shutdown process to proceed normally, the {{BasicDataSource}} to be 
closed, the Evictor thread to terminate, and VM to exit normally.


was (Author: jlandin):
PR - https://github.com/apache/commons-pool/pull/20
As described 
[here|https://docs.oracle.com/javase/8/docs/api/java/lang/Runtime.html#addShutdownHook-java.lang.Thread-],
 shutdown hooks cannot be started until all non-daemon threads have exited. In 
the case of commons-pool, historically the Evictor thread is not a daemon and 
does not exit while the object pool is open. This results in a deadlock in 
stand-alone application environments where DBCP is configured and managed by a 
Spring context, since the {{BasicDataSource}} is only closed during the Spring 
context shutdown hook. Changing the Evictor thread to be a daemon allows the 
Runtime shutdown process to proceed normally.

> Evictor Thread prevents Spring Context shutdown in standalone app
> -
>
> Key: POOL-363
> URL: https://issues.apache.org/jira/browse/POOL-363
> Project: Commons Pool
>  Issue Type: Bug
>Affects Versions: 2.4.3, 2.5.0, 2.6.0, 2.6.1
> Environment: Java {{1.8.0_92}}
>Reporter: Josh Landin
>Priority: Major
> Attachments: 2019.03.26_screen281.jpg
>
>  Time Spent: 10m
>  Remaining Estimate: 0h
>
> Given a DBCP2 connection pool configured in a Spring Application context with 
> the POOL evictor thread enabled, a standalone main() application hangs on 
> shutdown. Example below:
> Maven pom.xml:
> {code:xml}
>   
> 
>   org.apache.commons
>   commons-dbcp2
>   2.6.0
> 
> 
>   mysql
>   mysql-connector-java
>   8.0.15
> 
> 
>   org.springframework
>   spring-context
>   5.1.5.RELEASE
> 
>   
> {code}
> MainTest.java:
> {code:java}
> import java.sql.Connection;
> import java.sql.ResultSet;
> import java.sql.SQLException;
> import java.sql.Statement;
> import javax.sql.DataSource;
> import org.apache.commons.dbcp2.BasicDataSource;
> import 
> org.springframework.context.annotation.AnnotationConfigApplicationContext;
> import org.springframework.context.annotation.Bean;
> import org.springframework.context.annotation.Configuration;
> public class MainTest
> {
>   @Configuration
>   public static class Config 
>   {
> @Bean
> public DataSource getBasicDataSource()
> {
>   BasicDataSource d = new BasicDataSource();
>   d.setUrl("jdbc:mysql://localhost:3306/anydb");
>   d.setUsername("myuser");
>   d.setPassword("mypass");
>   d.setTimeBetweenEvictionRunsMillis(1000); // Turn on Evictor Thread.
>   return d;
> }
>   }
>   public static void main(String[] args)
>   {
> AnnotationConfigApplicationContext ctx = new 
> AnnotationConfigApplicationContext(Config.class);
> ctx.registerShutdownHook(); // Ensures context.close() on JVM shutdown.
> 
> try(
> Connection conn = ctx.getBean(BasicDataSource.class).getConnection(); 
> Statement stmt = conn.createStatement();
> ResultSet result = stmt.executeQuery("SELECT 1");
> )
> {
>   int records = result.last() ? result.getRow() : 0;
>   System.out.println("Records: "+records);
> }
> catch(SQLException e)
> {
>   e.printStackTrace();
> }
> System.out.println("End.");
>   }
> }
> {code}
> The issue is not present when turning off the eviction thread by setting 
> {{timeBetweenEvictionRunsMillis}} to {{-1}}.
> Jconsole thread summary attached for reference.



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


[jira] [Created] (NUMBERS-97) Remove commons-numbers-fraction *Format classes

2019-03-27 Thread Eric Barnhill (JIRA)
Eric Barnhill created NUMBERS-97:


 Summary: Remove commons-numbers-fraction *Format classes
 Key: NUMBERS-97
 URL: https://issues.apache.org/jira/browse/NUMBERS-97
 Project: Commons Numbers
  Issue Type: Task
Reporter: Eric Barnhill
Assignee: Eric Barnhill


Remove standalone Format classes in commons-numbers-fraction . 

Replace this functionality with VALJO-related parse() and toString() methods 
within Fraction and BigFraction



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


[jira] [Comment Edited] (STATISTICS-7) Stream-based Java statistical processing

2019-03-27 Thread Salman Hussain (JIRA)


[ 
https://issues.apache.org/jira/browse/STATISTICS-7?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16803193#comment-16803193
 ] 

Salman Hussain edited comment on STATISTICS-7 at 3/28/19 12:28 AM:
---

Thanks for the guidance [~ericbarnhill], I have been taking a look at the 
examples in scikit-learn - and perhaps instead of porting the regression 
library in commons.math.stat I could implement 
[sklearn.linear_model|https://scikit-learn.org/stable/modules/classes.html#module-sklearn.linear_model]
 in Java. The selection of linear regression methods seems to be more 
comprehensive and this is much needed within the package. The codebase would 
however be significantly larger. 



> Stream-based Java statistical processing
> 
>
> Key: STATISTICS-7
> URL: https://issues.apache.org/jira/browse/STATISTICS-7
> Project: Apache Commons Statistics
>  Issue Type: New Feature
>Reporter: Eric Barnhill
>Priority: Major
>  Labels: GSoC2019, gsoc2019, statistics, streams
>
> The new component aims to be a library of commons statistics functions 
> synchronized with the latest developments in the Java language, in particular 
> Java's functional programming syntax.
> The library will make commonly used statistical functions available to an end 
> user through a simple grammar comparable to commons-math-statistics or 
> scikit-learn, while under the hood will implement Java's mapping, streaming, 
> and other producer and consumer functions to ensure the statistical methods 
> run optimally in new Java implementations.
> Developers working on the project will have the opportunity to demonstrate 
> Java programming, functional programming, algorithm design, and data science 
> skills and receive authorship on a commons project that is likely to be 
> widely used.
> The ideal contributor will also be able to help with important architectural 
> decision making. The old source of these libraries, commons-math, grew too 
> large, hierarchically complex and interdependent for the commons mission. The 
> developers on this project need to make architectural choices that will 
> enable the statiscal code to be lightweight and reusable, with a minimum of 
> outside dependencies while avoiding redundancy.



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


[jira] [Comment Edited] (STATISTICS-7) Stream-based Java statistical processing

2019-03-27 Thread Salman Hussain (JIRA)


[ 
https://issues.apache.org/jira/browse/STATISTICS-7?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16802140#comment-16802140
 ] 

Salman Hussain edited comment on STATISTICS-7 at 3/28/19 12:29 AM:
---

Hi [~ericbarnhill], I am currently in my 2nd year of studying Computer Science 
at Imperial College London and I am interested in this project. I have lots of 
experience with functional programming in Java, and additionally have lots of 
familiarity with Haskell. I also have a strong knowledge base of statistics but 
lack experience in R. Would the main aim of the project to develop libraries of 
existing statistical methods using Java streams? Thanks!



> Stream-based Java statistical processing
> 
>
> Key: STATISTICS-7
> URL: https://issues.apache.org/jira/browse/STATISTICS-7
> Project: Apache Commons Statistics
>  Issue Type: New Feature
>Reporter: Eric Barnhill
>Priority: Major
>  Labels: GSoC2019, gsoc2019, statistics, streams
>
> The new component aims to be a library of commons statistics functions 
> synchronized with the latest developments in the Java language, in particular 
> Java's functional programming syntax.
> The library will make commonly used statistical functions available to an end 
> user through a simple grammar comparable to commons-math-statistics or 
> scikit-learn, while under the hood will implement Java's mapping, streaming, 
> and other producer and consumer functions to ensure the statistical methods 
> run optimally in new Java implementations.
> Developers working on the project will have the opportunity to demonstrate 
> Java programming, functional programming, algorithm design, and data science 
> skills and receive authorship on a commons project that is likely to be 
> widely used.
> The ideal contributor will also be able to help with important architectural 
> decision making. The old source of these libraries, commons-math, grew too 
> large, hierarchically complex and interdependent for the commons mission. The 
> developers on this project need to make architectural choices that will 
> enable the statiscal code to be lightweight and reusable, with a minimum of 
> outside dependencies while avoiding redundancy.



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


[jira] [Commented] (STATISTICS-7) Stream-based Java statistical processing

2019-03-27 Thread Gilles (JIRA)


[ 
https://issues.apache.org/jira/browse/STATISTICS-7?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16803493#comment-16803493
 ] 

Gilles commented on STATISTICS-7:
-

Hi [~Salman].

Could you please remove the restriction as to who can see your comments?
When one is not logged in, part of the conversation is missing and it looks 
quite odd...

Thanks.


> Stream-based Java statistical processing
> 
>
> Key: STATISTICS-7
> URL: https://issues.apache.org/jira/browse/STATISTICS-7
> Project: Apache Commons Statistics
>  Issue Type: New Feature
>Reporter: Eric Barnhill
>Priority: Major
>  Labels: GSoC2019, gsoc2019, statistics, streams
>
> The new component aims to be a library of commons statistics functions 
> synchronized with the latest developments in the Java language, in particular 
> Java's functional programming syntax.
> The library will make commonly used statistical functions available to an end 
> user through a simple grammar comparable to commons-math-statistics or 
> scikit-learn, while under the hood will implement Java's mapping, streaming, 
> and other producer and consumer functions to ensure the statistical methods 
> run optimally in new Java implementations.
> Developers working on the project will have the opportunity to demonstrate 
> Java programming, functional programming, algorithm design, and data science 
> skills and receive authorship on a commons project that is likely to be 
> widely used.
> The ideal contributor will also be able to help with important architectural 
> decision making. The old source of these libraries, commons-math, grew too 
> large, hierarchically complex and interdependent for the commons mission. The 
> developers on this project need to make architectural choices that will 
> enable the statiscal code to be lightweight and reusable, with a minimum of 
> outside dependencies while avoiding redundancy.



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


[jira] [Comment Edited] (STATISTICS-7) Stream-based Java statistical processing

2019-03-27 Thread Salman Hussain (JIRA)


[ 
https://issues.apache.org/jira/browse/STATISTICS-7?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16802232#comment-16802232
 ] 

Salman Hussain edited comment on STATISTICS-7 at 3/28/19 12:28 AM:
---

Hey [~ericbarnhill], sounds good! It might be beneficial to start with the 
seemingly slightly easier parts of summary statistics before moving onto either 
more obscure parts or the regression library that seems more interesting! Of 
course timescale is important when making the proposal, could you shed some 
light on the estimated time you reckon each part could take? I will explore 
some of the topics you have mentioned and draw up a proposal. Will you be able 
to have a read through this before I submit to GSoC? Thanks! 



> Stream-based Java statistical processing
> 
>
> Key: STATISTICS-7
> URL: https://issues.apache.org/jira/browse/STATISTICS-7
> Project: Apache Commons Statistics
>  Issue Type: New Feature
>Reporter: Eric Barnhill
>Priority: Major
>  Labels: GSoC2019, gsoc2019, statistics, streams
>
> The new component aims to be a library of commons statistics functions 
> synchronized with the latest developments in the Java language, in particular 
> Java's functional programming syntax.
> The library will make commonly used statistical functions available to an end 
> user through a simple grammar comparable to commons-math-statistics or 
> scikit-learn, while under the hood will implement Java's mapping, streaming, 
> and other producer and consumer functions to ensure the statistical methods 
> run optimally in new Java implementations.
> Developers working on the project will have the opportunity to demonstrate 
> Java programming, functional programming, algorithm design, and data science 
> skills and receive authorship on a commons project that is likely to be 
> widely used.
> The ideal contributor will also be able to help with important architectural 
> decision making. The old source of these libraries, commons-math, grew too 
> large, hierarchically complex and interdependent for the commons mission. The 
> developers on this project need to make architectural choices that will 
> enable the statiscal code to be lightweight and reusable, with a minimum of 
> outside dependencies while avoiding redundancy.



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


[jira] [Commented] (STATISTICS-7) Stream-based Java statistical processing

2019-03-27 Thread Eric Barnhill (JIRA)


[ 
https://issues.apache.org/jira/browse/STATISTICS-7?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16803477#comment-16803477
 ] 

Eric Barnhill commented on STATISTICS-7:


Sounds very ambitious – just make sure you start with linear and logistic 
regression before you head to anything fancier. :) Obviously work can continue 
after summer's end if there is interest.

> Stream-based Java statistical processing
> 
>
> Key: STATISTICS-7
> URL: https://issues.apache.org/jira/browse/STATISTICS-7
> Project: Apache Commons Statistics
>  Issue Type: New Feature
>Reporter: Eric Barnhill
>Priority: Major
>  Labels: GSoC2019, gsoc2019, statistics, streams
>
> The new component aims to be a library of commons statistics functions 
> synchronized with the latest developments in the Java language, in particular 
> Java's functional programming syntax.
> The library will make commonly used statistical functions available to an end 
> user through a simple grammar comparable to commons-math-statistics or 
> scikit-learn, while under the hood will implement Java's mapping, streaming, 
> and other producer and consumer functions to ensure the statistical methods 
> run optimally in new Java implementations.
> Developers working on the project will have the opportunity to demonstrate 
> Java programming, functional programming, algorithm design, and data science 
> skills and receive authorship on a commons project that is likely to be 
> widely used.
> The ideal contributor will also be able to help with important architectural 
> decision making. The old source of these libraries, commons-math, grew too 
> large, hierarchically complex and interdependent for the commons mission. The 
> developers on this project need to make architectural choices that will 
> enable the statiscal code to be lightweight and reusable, with a minimum of 
> outside dependencies while avoiding redundancy.



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


[jira] [Commented] (JEXL-293) leading plus sign not recognized

2019-03-27 Thread Sharon Ben Asher (JIRA)


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

Sharon Ben Asher commented on JEXL-293:
---

I am OK to use snapshot version.
I am not angry. I did not understand why I need to explain something that is 
obvious in my eyes. 

> leading plus sign not recognized
> 
>
> Key: JEXL-293
> URL: https://issues.apache.org/jira/browse/JEXL-293
> Project: Commons JEXL
>  Issue Type: Bug
>Affects Versions: 3.1
>Reporter: Sharon Ben Asher
>Assignee: Henri Biestro
>Priority: Major
>
> The expression "+2" is not valid ?



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


[jira] [Work logged] (POOL-363) Evictor Thread prevents Spring Context shutdown in standalone app

2019-03-27 Thread ASF GitHub Bot (JIRA)


 [ 
https://issues.apache.org/jira/browse/POOL-363?focusedWorklogId=219783=com.atlassian.jira.plugin.system.issuetabpanels:worklog-tabpanel#worklog-219783
 ]

ASF GitHub Bot logged work on POOL-363:
---

Author: ASF GitHub Bot
Created on: 28/Mar/19 02:59
Start Date: 28/Mar/19 02:59
Worklog Time Spent: 10m 
  Work Description: coveralls commented on issue #20: Fix for POOL-363
URL: https://github.com/apache/commons-pool/pull/20#issuecomment-477427057
 
 
   
   [![Coverage 
Status](https://coveralls.io/builds/22447120/badge)](https://coveralls.io/builds/22447120)
   
   Coverage increased (+0.07%) to 85.246% when pulling 
**7ad4231e157bbcb2f9b1c04c8247b76ea2565999 on joshlandin:master** into 
**ac214bfcc63761ac440785675a0bed7d2798ec96 on apache:master**.
   
 

This is an automated message from the Apache Git Service.
To respond to the message, please log on to GitHub and use the
URL above to go to the specific comment.
 
For queries about this service, please contact Infrastructure at:
us...@infra.apache.org


Issue Time Tracking
---

Worklog Id: (was: 219783)
Time Spent: 20m  (was: 10m)

> Evictor Thread prevents Spring Context shutdown in standalone app
> -
>
> Key: POOL-363
> URL: https://issues.apache.org/jira/browse/POOL-363
> Project: Commons Pool
>  Issue Type: Bug
>Affects Versions: 2.4.3, 2.5.0, 2.6.0, 2.6.1
> Environment: Java {{1.8.0_92}}
>Reporter: Josh Landin
>Priority: Major
> Attachments: 2019.03.26_screen281.jpg
>
>  Time Spent: 20m
>  Remaining Estimate: 0h
>
> Given a DBCP2 connection pool configured in a Spring Application context with 
> the POOL evictor thread enabled, a standalone main() application hangs on 
> shutdown. Example below:
> Maven pom.xml:
> {code:xml}
>   
> 
>   org.apache.commons
>   commons-dbcp2
>   2.6.0
> 
> 
>   mysql
>   mysql-connector-java
>   8.0.15
> 
> 
>   org.springframework
>   spring-context
>   5.1.5.RELEASE
> 
>   
> {code}
> MainTest.java:
> {code:java}
> import java.sql.Connection;
> import java.sql.ResultSet;
> import java.sql.SQLException;
> import java.sql.Statement;
> import javax.sql.DataSource;
> import org.apache.commons.dbcp2.BasicDataSource;
> import 
> org.springframework.context.annotation.AnnotationConfigApplicationContext;
> import org.springframework.context.annotation.Bean;
> import org.springframework.context.annotation.Configuration;
> public class MainTest
> {
>   @Configuration
>   public static class Config 
>   {
> @Bean
> public DataSource getBasicDataSource()
> {
>   BasicDataSource d = new BasicDataSource();
>   d.setUrl("jdbc:mysql://localhost:3306/anydb");
>   d.setUsername("myuser");
>   d.setPassword("mypass");
>   d.setTimeBetweenEvictionRunsMillis(1000); // Turn on Evictor Thread.
>   return d;
> }
>   }
>   public static void main(String[] args)
>   {
> AnnotationConfigApplicationContext ctx = new 
> AnnotationConfigApplicationContext(Config.class);
> ctx.registerShutdownHook(); // Ensures context.close() on JVM shutdown.
> 
> try(
> Connection conn = ctx.getBean(BasicDataSource.class).getConnection(); 
> Statement stmt = conn.createStatement();
> ResultSet result = stmt.executeQuery("SELECT 1");
> )
> {
>   int records = result.last() ? result.getRow() : 0;
>   System.out.println("Records: "+records);
> }
> catch(SQLException e)
> {
>   e.printStackTrace();
> }
> System.out.println("End.");
>   }
> }
> {code}
> The issue is not present when turning off the eviction thread by setting 
> {{timeBetweenEvictionRunsMillis}} to {{-1}}.
> Jconsole thread summary attached for reference.



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


[GitHub] [commons-pool] coveralls commented on issue #20: Fix for POOL-363

2019-03-27 Thread GitBox
coveralls commented on issue #20: Fix for POOL-363
URL: https://github.com/apache/commons-pool/pull/20#issuecomment-477427057
 
 
   
   [![Coverage 
Status](https://coveralls.io/builds/22447120/badge)](https://coveralls.io/builds/22447120)
   
   Coverage increased (+0.07%) to 85.246% when pulling 
**7ad4231e157bbcb2f9b1c04c8247b76ea2565999 on joshlandin:master** into 
**ac214bfcc63761ac440785675a0bed7d2798ec96 on apache:master**.
   


This is an automated message from the Apache Git Service.
To respond to the message, please log on to GitHub and use the
URL above to go to the specific comment.
 
For queries about this service, please contact Infrastructure at:
us...@infra.apache.org


With regards,
Apache Git Services