[jira] [Created] (JEXL-294) expression:b == true , when b="abc" then return true
锁战强 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
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
[ 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
[ 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
[ 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
[ 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
[ 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
[ 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
[ 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
[ 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
[ 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
[ 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
[ 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
[ 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
[ 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
[ 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
[ 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
[ 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
[ 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
[ 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
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
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
[ 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
[ 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
[ 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
[ 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
[ 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
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
[ 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
[ 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
[ 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
[ 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
[ 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
[ 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
[ 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
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