[jira] [Comment Edited] (JEXL-367) Deprecate -> and support =>
[
https://issues.apache.org/jira/browse/JEXL-367?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=17531494#comment-17531494
]
Hussachai Puripunpinyo edited comment on JEXL-367 at 5/4/22 6:08 AM:
-
[~henrib] We added a ton of things to JEXL. We also removed a lot of things
from JEXL.
For example, this one will work on our JEXL fork as well as JS
{code:java}
var list = [1, 2, 3];
var r = list.map(x => {return x * x}).reduce((acc, x) => { return acc + x});
console.log(r) {code}
We have data binding for Scala and Kotlin. When the list literal above is used
in Scala environment, it produces scala.immutable.List instead of
java.util.List. The map, reduce, and other functions defined in JS work out of
the box.
We also unwrap Java Optional, Scala Option, Kotlin Arrow Option and other
monadic types like Either and Try by default.
The dot notation (object navigation) is null-safe by default. So, for the
expression like a.b.c
if a is null, it's still fine. If b is Option, it will be unwrapped. There is
no other language can beat this succinctness :)
My users understand that this is not JS and they actually like it more than JS.
Like the above example. The return keyword can be omitted in JEXL but it's
required in JS. The JSON navigation works out of the box and it doesn't matter
what JSON library they are using, our JEXL fork understands their JSON tree and
walks it as if it is a regular object.
The code is hosted in my company private repo and I'm kinda believe that it's
hard to request it to be open source due to security concerns.
[~dmitri_blinov] You have a valid point, but I don't think it is good for JEXL
to be a unique language by its own. Honestly, JEXL as a language doesn't stand
a chance to compete with other languages out there. To be unique and making it
worth learning must come with substantial benefits that users will gain. The
key point is familiarity. Users tend to prefer utilizing existing knowledge if
possible.
I like that JEXL is similar to JS and it has some unique features that make it
even better for quick and dirty scripting (JEXL is much better than Coffescript
for example). My JEXL fork is also much more succinct than JS and it works well
across different JVM languages. Thanks to the extensibility of JEXL.
Before JEXL, we did use Nashorn as our javascript engine. It's not quite
secure, and the performance is really poor. On top of that, Nashorn has its own
types that we have to convert back and forth (We cannot create a native binding
so there is a big overhead right there). We cannot reuse existing
Java/Kotlin/Scala libraries there. Putting JS libraries and interpreting the
whole thing takes enormous time and resource. So, we didn't even dare to think
about doing it :D Later, Oracle announced that they would deprecate Nashorn in
Java11, and it was the last string for us. We were uncertain with the future of
the engine. So we dropped it and looked for another simple language to use.
Luckily I found the hidden gem, JEXL. So, we extended it instead of building
everything from scratch. Since Rhino is mentioned, I can tell you that Nashorn
is slow but it's still way faster than Rhino. Using JS engine in JVM, it means
we also have to deal with the platform compatibility and the code base that is
way harder to comprehend than JEXL because the full JS implementation is very
very complex.
was (Author: hussachai):
[~henrib] We added a ton of things to JEXL. We also removed a lot of things
from JEXL.
For example, this one will work on our JEXL fork as well as JS
{code:java}
var list = [1, 2, 3];
var r = list.map(x => {return x * x}).reduce((acc, x) => { return acc + x});
console.log(r) {code}
We have data binding for Scala and Kotlin. When the list literal above is used
in Scala environment, it produces scala.immutable.List instead of
java.util.List. The map, reduce, and other functions defined in JS work out of
the box.
We also unwrap Java Optional, Scala Option, Kotlin Arrow Option and other
monadic types like Either and Try by default.
The dot notation (object navigation) is null-safe by default. So, for the
expression like a.b.c
if a is null, it's still fine. If b is Option, it will be unwrapped. There is
no other language can beat this succinctness :)
We also have some weird features that some objects can behave differently based
on the context it is used. Some objects can yield a dynamically computed value
instead of the object itself.
My users understand that this is not JS and they actually like it more than JS.
Like the above example. The return keyword can be omitted in JEXL but it's
required in JS. The JSON navigation works out of the box and it doesn't matter
what JSON library they are using, our JEXL fork understands their JSON tree and
walks it as if it is a regular object.
Unfortunately, the code is hosted in
[jira] [Commented] (JEXL-367) Deprecate -> and support =>
[
https://issues.apache.org/jira/browse/JEXL-367?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=17531494#comment-17531494
]
Hussachai Puripunpinyo commented on JEXL-367:
-
[~henrib] We added a ton of things to JEXL. We also removed a lot of things
from JEXL.
For example, this one will work on our JEXL fork as well as JS
{code:java}
var list = [1, 2, 3];
var r = list.map(x => {return x * x}).reduce((acc, x) => { return acc + x});
console.log(r) {code}
We have data binding for Scala and Kotlin. When the list literal above is used
in Scala environment, it produces scala.immutable.List instead of
java.util.List. The map, reduce, and other functions defined in JS work out of
the box.
We also unwrap Java Optional, Scala Option, Kotlin Arrow Option and other
monadic types like Either and Try by default.
The dot notation (object navigation) is null-safe by default. So, for the
expression like a.b.c
if a is null, it's still fine. If b is Option, it will be unwrapped. There is
no other language can beat this succinctness :)
We also have some weird features that some objects can behave differently based
on the context it is used. Some objects can yield a dynamically computed value
instead of the object itself.
My users understand that this is not JS and they actually like it more than JS.
Like the above example. The return keyword can be omitted in JEXL but it's
required in JS. The JSON navigation works out of the box and it doesn't matter
what JSON library they are using, our JEXL fork understands their JSON tree and
walks it as if it is a regular object.
Unfortunately, the code is hosted in my company private repo and I'm kinda
believe that it's hard to request it to be open source
due to security concerns.
[~dmitri_blinov] You have a valid point, but I don't think it is good for JEXL
to be a unique language by its own. Honestly, JEXL as a language doesn't stand
a chance to compete with other languages out there. To be unique and making it
worth learning must come with substantial benefits that users will gain. The
key point is familiarity as most of my users do not want to be a JEXL expert.
My target users are not even a software engineer. They want to get the job done
with minimum effort. They usually don't care much about the beauty of code or
how smart the language is. They just want to utilize their existing knowledge.
I like that JEXL is similar to JS and it has some unique features that make it
even better for quick and dirty scripting (JEXL is much better than Coffescript
for example). My JEXL fork is also much more succinct than JS and it works well
across different JVM languages. Thanks to the extensibility of JEXL.
Before JEXL, we did use Nashorn as our javascript engine. It's not quite
secure, and the performance is really poor. On top of that, Nashorn has its own
types that we have to convert back and forth (We cannot create a native binding
so there is a big overhead right there). We cannot reuse existing
Java/Kotlin/Scala libraries there. Putting JS libraries and interpreting the
whole thing takes enormous time and resource. So, we didn't even dare to think
about doing it :D Later, Oracle announced that they would deprecate Nashorn in
Java11, and it was the last string for us. We were uncertain with the future of
the engine. So we dropped it and looked for another simple language to use.
Luckily I found the hidden gem, JEXL. So, we extended it instead of building
everything from scratch. Since Rhino is mentioned, I can tell you that Nashorn
is slow but it's still way faster than Rhino. Using JS engine in JVM, it means
we also have to deal with the platform compatibility and the code base that is
way harder to comprehend than JEXL because the full JS implementation is very
very complex.
> Deprecate -> and support =>
> ---
>
> Key: JEXL-367
> URL: https://issues.apache.org/jira/browse/JEXL-367
> Project: Commons JEXL
> Issue Type: Wish
>Affects Versions: 3.2.1
>Reporter: Hussachai Puripunpinyo
>Assignee: Henri Biestro
>Priority: Major
>
> The JEXL code surprisingly looks a lot like Javascript. I think this change
> is a good transition for folks to update the code, and it's pretty fine if
> they can tolerate using the deprecate syntax and don't mind seeing a warning
> log pop up every time.
> I'd like to propose supporting => and deprecate ->.
> The reasons are
> - JavaScript becomes very popular and many people are familiar with it.
> - JEXL is more like for a quick short script. In many scenarios, the target
> audiences are not a programer. They often mistake a language as a JavaScript
> (from my experience).
> - JEXL syntax already looks a lot like JavaScript
> -- var for variable declaration (Java added in Java 10, but JavaSc
[jira] [Comment Edited] (JEXL-367) Deprecate -> and support =>
[ https://issues.apache.org/jira/browse/JEXL-367?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=17531040#comment-17531040 ] Hussachai Puripunpinyo edited comment on JEXL-367 at 5/4/22 4:25 AM: - I know you are not asking me but since I like JEXL approach for the most part. So I'd like to voice my opinion a little bit here. Java is a statically typed language. JEXL is not built for a big sophisticate code. It's for a quick and probably dirty script that can get the job done. Statically type for this kind of job is overkill. Also, it's quite complex to built a statically typed language. Groovy has a very small user base. Many people don't even know that this language exists. The only thing that keeps it alive is gradle. I'm sure Kotlin will take over that space soon. and Grails is .. what is that? Python is not JVM. (I know there was Jython/JPython and it's long gone). Python is a dynamically typed language and it's very good for scripting too. Everything looks good except that indentations that can throw many people off. Also, It'll be very hard to embed python code in Java when multiline string is not supported (I know it's now possible with Java 15). I don't think there is anything so special about JS. It's just popular and a lot of people know it. I believe my PM can write a basic JS code. The documentation/books/tutorial are everywhere. Anyone can try it out quickly without installing anything. It's just about familiarity. I advertise my JEXL fork as a subset of JavaScript on steroid. We support a lot of JS functions and most of the time, JEXL code written by our users can be run in the web browser too. If JEXL is not resemble to JS, I'd have a question too. Why not JS? was (Author: hussachai): I know you are not asking me but since I like JEXL approach for the most part. So I'd like to voice my opinion a little bit here. Java is a statically typed language. JEXL is not built for a big sophisticate code. It's for a quick and probably dirty script that can get the job done. Statically type for this kind of job is overkill. Also, it's quite complex to built a statically typed language. Groovy has a very small user base. Many people don't even know that this language exists. The only thing that keeps it alive is gradle. I'm sure Kotlin will take over that space soon. and Grails is .. what is that? Python is not JVM. (I know there was Jython/JPython and it's long gone). Python is a dynamically typed language and it's very good for scripting too. Everything looks good exception indentations that can throw many people off. Also, It'll be very hard to embed python code in Java when multiline string is not supported (I know it's now possible with Java 15). I don't think there is anything so special about JS. It's just popular and a lot of people know it. I believe my PM can write a basic JS code. The documentation/books/tutorial are everywhere. Anyone can try it out quickly without installing anything. It's just about familiarity. I advertise my JEXL fork as a subset of JavaScript on steroid. We support a lot of JS functions and most of the time, JEXL code written by our users can be run in the web browser too. If JEXL is not resemble to JS, I'd have a question too. Why not JS? > Deprecate -> and support => > --- > > Key: JEXL-367 > URL: https://issues.apache.org/jira/browse/JEXL-367 > Project: Commons JEXL > Issue Type: Wish >Affects Versions: 3.2.1 >Reporter: Hussachai Puripunpinyo >Assignee: Henri Biestro >Priority: Major > > The JEXL code surprisingly looks a lot like Javascript. I think this change > is a good transition for folks to update the code, and it's pretty fine if > they can tolerate using the deprecate syntax and don't mind seeing a warning > log pop up every time. > I'd like to propose supporting => and deprecate ->. > The reasons are > - JavaScript becomes very popular and many people are familiar with it. > - JEXL is more like for a quick short script. In many scenarios, the target > audiences are not a programer. They often mistake a language as a JavaScript > (from my experience). > - JEXL syntax already looks a lot like JavaScript > -- var for variable declaration (Java added in Java 10, but JavaScript > supports this from the beginning) > -- The function keyword > -- Implicit type coercion > -- Ternary operator > The proposed change. > * Support => in addition to -> > * Deprecate -> and show a warning log when it's used. -- This message was sent by Atlassian Jira (v8.20.7#820007)
[jira] [Resolved] (GEOMETRY-147) BoundsXD Linecastable
[
https://issues.apache.org/jira/browse/GEOMETRY-147?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Matt Juntunen resolved GEOMETRY-147.
Resolution: Done
> BoundsXD Linecastable
> -
>
> Key: GEOMETRY-147
> URL: https://issues.apache.org/jira/browse/GEOMETRY-147
> Project: Commons Geometry
> Issue Type: New Feature
>Reporter: Matt Juntunen
>Priority: Major
> Fix For: 1.1
>
>
> Make the {{Bounds2D}} and {{Bounds3D}} classes implement {{Linecastable}}.
> Use the
> ["slabs"|https://education.siggraph.org/static/HyperGraph/raytrace/rtinter3.htm]
> algorithm to determine intersection points.
--
This message was sent by Atlassian Jira
(v8.20.7#820007)
[jira] [Commented] (GEOMETRY-147) BoundsXD Linecastable
[
https://issues.apache.org/jira/browse/GEOMETRY-147?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=17531473#comment-17531473
]
Matt Juntunen commented on GEOMETRY-147:
Merged in commit 27b8d65ad6900af39b6036d8a00dcd8d448c99ee
> BoundsXD Linecastable
> -
>
> Key: GEOMETRY-147
> URL: https://issues.apache.org/jira/browse/GEOMETRY-147
> Project: Commons Geometry
> Issue Type: New Feature
>Reporter: Matt Juntunen
>Priority: Major
> Fix For: 1.1
>
>
> Make the {{Bounds2D}} and {{Bounds3D}} classes implement {{Linecastable}}.
> Use the
> ["slabs"|https://education.siggraph.org/static/HyperGraph/raytrace/rtinter3.htm]
> algorithm to determine intersection points.
--
This message was sent by Atlassian Jira
(v8.20.7#820007)
[GitHub] [commons-geometry] asfgit merged pull request #196: GEOMETRY-147: Bounds Linecast
asfgit merged PR #196: URL: https://github.com/apache/commons-geometry/pull/196 -- 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. To unsubscribe, e-mail: issues-unsubscr...@commons.apache.org For queries about this service, please contact Infrastructure at: us...@infra.apache.org
[jira] [Commented] (JEXL-367) Deprecate -> and support =>
[ https://issues.apache.org/jira/browse/JEXL-367?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=17531394#comment-17531394 ] Dmitri Blinov commented on JEXL-367: [~hussachai] thanks for the thorough observation, but my question was rather about why trying to make JEXL yet another JS, groovy or you name it. One probably won’t get close to the original, and what is the point of being half alike? There are open projects like aforementioned rhino, that one can freely use now-days and enjoy bells and whistles. But IMO, in JEXL world you will hardly make variables work like JS ones, regarding redefinition, hoisting and capturing behavior, without overcomplicating the long existing concept of context and local variables with toggles and features. [~henrib] I think JS have coined some cool features, that JEXL can surely benefit from, but IMO its variable model is not one of them, are you sure you want let it ‘let’ ?:) > Deprecate -> and support => > --- > > Key: JEXL-367 > URL: https://issues.apache.org/jira/browse/JEXL-367 > Project: Commons JEXL > Issue Type: Wish >Affects Versions: 3.2.1 >Reporter: Hussachai Puripunpinyo >Assignee: Henri Biestro >Priority: Major > > The JEXL code surprisingly looks a lot like Javascript. I think this change > is a good transition for folks to update the code, and it's pretty fine if > they can tolerate using the deprecate syntax and don't mind seeing a warning > log pop up every time. > I'd like to propose supporting => and deprecate ->. > The reasons are > - JavaScript becomes very popular and many people are familiar with it. > - JEXL is more like for a quick short script. In many scenarios, the target > audiences are not a programer. They often mistake a language as a JavaScript > (from my experience). > - JEXL syntax already looks a lot like JavaScript > -- var for variable declaration (Java added in Java 10, but JavaScript > supports this from the beginning) > -- The function keyword > -- Implicit type coercion > -- Ternary operator > The proposed change. > * Support => in addition to -> > * Deprecate -> and show a warning log when it's used. -- This message was sent by Atlassian Jira (v8.20.7#820007)
[jira] [Comment Edited] (POOL-282) CLONE - Support AbandonedConfig in SharedPoolDataSource
[ https://issues.apache.org/jira/browse/POOL-282?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=17531339#comment-17531339 ] Phil Steitz edited comment on POOL-282 at 5/3/22 6:08 PM: -- [~ashok2ashok] First, many thanks for stepping up to the challenge here. Here are some comments: # I don't think we need to support different abandoned configs for different keys. That would be kind of messy and I can't immediately think of scenarios where different configs would be desired. Does your use case require this? Assuming no, I would stick with just using the AbandonedConfig class as is. # The per key considerations come in when you actually do the cleanup. It seems reasonable to me to generally follow the pattern of what GOP does, except that you add the key as a parameter to removeAbandoned, so it is ``removeAbandoned(ac, key)`` and it does what the signature suggests - just goes after abandoned instances under the given key. So borrowObject does the same kind of test that GOP does and if the pool is running low for the given key, it does the cleanup for that key. # Maintenance is kind of interesting. The natural thing to do would be to iterate all keys and call ``removeAbandoned(ac, key)`` for all of them. For pools with lots of keys, that might cause performance problems. I can see three options here: 0) don't worry about it 1) hitchhike on the iteration sequence in the loop over numTests in evict and just hit the keys that get visited 2) introduce a separate config that controls how many keys get cleaned up per eviction run and maintain a separate keys iterator to cycle through them. Could be I am needlessly worrying here and 0) is fine. The whole thing can be turned off by setting removeAbandonedOnMaintenance to false so I think it is probably OK to start with the simple hit them all impl. was (Author: psteitz): [~ashok2ashok] First, many thanks for stepping up to the challenge here. Here are some comments: # I don't think we need to support different abandoned configs for different keys. That would be kind of messy and I can't immediately think of scenarios where different configs would be desired. Does your use case require this? Assuming no, I would stick with just using the AbandonedConfig class as is. # The per key considerations come in when you actually do the cleanup. It seems reasonable to me to generally follow the pattern of what GOP does, except that you add the key as a parameter to removeAbandoned, so it is `removeAbandoned(ac, key)` and it does what the signature suggests - just goes after abandoned instances under the given key. So borrowObject does the same kind of test that GOP does and if the pool is running low for the given key, it does the cleanup for that key. # Maintenance is kind of interesting. The natural thing to do would be to iterate all keys and call `removeAbandoned(ac, key)` for all of them. For pools with lots of keys, that might cause performance problems. I can see three options here: 0) don't worry about it 1) hitchhike on the iteration sequence in the loop over numTests in evict and just hit the keys that get visited 2) introduce a separate config that controls how many keys get cleaned up per eviction run and maintain a separate keys iterator to cycle through them. Could be I am needlessly worrying here and 0) is fine. The whole thing can be turned off by setting removeAbandonedOnMaintenance to false so I think it is probably OK to start with the simple hit them all impl. > CLONE - Support AbandonedConfig in SharedPoolDataSource > --- > > Key: POOL-282 > URL: https://issues.apache.org/jira/browse/POOL-282 > Project: Commons Pool > Issue Type: Improvement >Affects Versions: 2.0, 2.1, 2.2, 2.3 > Environment: Linux and Java 1.6 >Reporter: Michael Kerr >Priority: Minor > Labels: features > > BasicDataSource has support for AbandonedConfig > SharedPoolDataSource does not currently support reclaiming abandoned > connections. > It would be helpful if the user can extend the underlying connection pool to > add features like abandoned connection management. This is possible with > BasicDataSource. > Currently the only solution is to extend classes or replace classes in the > Apache package namespace. > Thanks for looking, > Michael -- This message was sent by Atlassian Jira (v8.20.7#820007)
[jira] [Commented] (POOL-282) CLONE - Support AbandonedConfig in SharedPoolDataSource
[ https://issues.apache.org/jira/browse/POOL-282?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=17531339#comment-17531339 ] Phil Steitz commented on POOL-282: -- [~ashok2ashok] First, many thanks for stepping up to the challenge here. Here are some comments: # I don't think we need to support different abandoned configs for different keys. That would be kind of messy and I can't immediately think of scenarios where different configs would be desired. Does your use case require this? Assuming no, I would stick with just using the AbandonedConfig class as is. # The per key considerations come in when you actually do the cleanup. It seems reasonable to me to generally follow the pattern of what GOP does, except that you add the key as a parameter to removeAbandoned, so it is `removeAbandoned(ac, key)` and it does what the signature suggests - just goes after abandoned instances under the given key. So borrowObject does the same kind of test that GOP does and if the pool is running low for the given key, it does the cleanup for that key. # Maintenance is kind of interesting. The natural thing to do would be to iterate all keys and call `removeAbandoned(ac, key)` for all of them. For pools with lots of keys, that might cause performance problems. I can see three options here: 0) don't worry about it 1) hitchhike on the iteration sequence in the loop over numTests in evict and just hit the keys that get visited 2) introduce a separate config that controls how many keys get cleaned up per eviction run and maintain a separate keys iterator to cycle through them. Could be I am needlessly worrying here and 0) is fine. The whole thing can be turned off by setting removeAbandonedOnMaintenance to false so I think it is probably OK to start with the simple hit them all impl. > CLONE - Support AbandonedConfig in SharedPoolDataSource > --- > > Key: POOL-282 > URL: https://issues.apache.org/jira/browse/POOL-282 > Project: Commons Pool > Issue Type: Improvement >Affects Versions: 2.0, 2.1, 2.2, 2.3 > Environment: Linux and Java 1.6 >Reporter: Michael Kerr >Priority: Minor > Labels: features > > BasicDataSource has support for AbandonedConfig > SharedPoolDataSource does not currently support reclaiming abandoned > connections. > It would be helpful if the user can extend the underlying connection pool to > add features like abandoned connection management. This is possible with > BasicDataSource. > Currently the only solution is to extend classes or replace classes in the > Apache package namespace. > Thanks for looking, > Michael -- This message was sent by Atlassian Jira (v8.20.7#820007)
[GitHub] [commons-jexl] henrib merged pull request #94: JEXL-368: refactored namespace resolution and cache functor properly
henrib merged PR #94: URL: https://github.com/apache/commons-jexl/pull/94 -- 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. To unsubscribe, e-mail: issues-unsubscr...@commons.apache.org For queries about this service, please contact Infrastructure at: us...@infra.apache.org
[jira] [Created] (JEXL-369) Add 'let' and 'const' variable declarations
Henri Biestro created JEXL-369: -- Summary: Add 'let' and 'const' variable declarations Key: JEXL-369 URL: https://issues.apache.org/jira/browse/JEXL-369 Project: Commons JEXL Issue Type: Improvement Affects Versions: 3.2.1 Reporter: Henri Biestro Assignee: Henri Biestro Fix For: 3.3 WHAT: Add creation of lexical scope variables, modifiable with 'let', non-modifiable through 'const'. -- This message was sent by Atlassian Jira (v8.20.7#820007)
[jira] [Updated] (JEXL-368) Namespace functor resolution is not cached
[ https://issues.apache.org/jira/browse/JEXL-368?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Henri Biestro updated JEXL-368: --- Description: WHAT: It appears that when the namespace points to a class, its constructor (wrapped in the JexlMethod) is not cached properly in the corresponding JexlNode. Incidentally, the call to the cached method is wrong too. (Detected through jacoco coverage). HOW: Cache the method/ctor (as a NamespaceFunctor) in the namespace identifier (the first child), not the method/funcalll node. was: WHAT: It appears that when the namespace points to a class, its constructor (wrapped in the JexlMethod) is not cached properly in the corresponding JexlNode. Incidentally, the call to the cached method is wrong too. (Detected through jacoco coverage). HOW: Cache the method in the namespace identifier (the first child), not the namespace node. > Namespace functor resolution is not cached > -- > > Key: JEXL-368 > URL: https://issues.apache.org/jira/browse/JEXL-368 > Project: Commons JEXL > Issue Type: Bug >Affects Versions: 3.2.1 >Reporter: Henri Biestro >Assignee: Henri Biestro >Priority: Minor > Fix For: 3.3 > > > WHAT: > It appears that when the namespace points to a class, its constructor > (wrapped in the JexlMethod) is not cached properly in the corresponding > JexlNode. Incidentally, the call to the cached method is wrong too. (Detected > through jacoco coverage). > HOW: > Cache the method/ctor (as a NamespaceFunctor) in the namespace identifier > (the first child), not the method/funcalll node. -- This message was sent by Atlassian Jira (v8.20.7#820007)
[jira] [Updated] (POOL-242) Set thread name for EvictionTimer
[ https://issues.apache.org/jira/browse/POOL-242?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Gary D. Gregory updated POOL-242: - Fix Version/s: (was: 1.6.1) (was: 1.5.8) > Set thread name for EvictionTimer > - > > Key: POOL-242 > URL: https://issues.apache.org/jira/browse/POOL-242 > Project: Commons Pool > Issue Type: Improvement >Affects Versions: 1.5, 1.6, 2.0, 2.1, 2.2, 2.3 >Reporter: Peter Plosz >Priority: Trivial > > Setting up thread name for EvictionTimer makes life easier when debugging > issues. -- This message was sent by Atlassian Jira (v8.20.7#820007)
[jira] [Updated] (POOL-264) NullPointerException in GKOP.borrowObject()
[ https://issues.apache.org/jira/browse/POOL-264?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Gary D. Gregory updated POOL-264: - Fix Version/s: (was: 1.6.1) (was: 1.5.8) > NullPointerException in GKOP.borrowObject() > --- > > Key: POOL-264 > URL: https://issues.apache.org/jira/browse/POOL-264 > Project: Commons Pool > Issue Type: Bug >Affects Versions: 1.5.6, 1.5.7, 1.6 >Reporter: Leonid Meyerguz >Priority: Major > > While I cannot pin down a consistent repro, I occasionally observe a > NullPointerException at > org.apache.commons.pool.impl.GenericKeyedObjectPool.borrowObject(GenericKeyedObjectPool.java:1126) > The pool is configured as follows: > maxActive = -1 > maxIdle = 32 > maxTotal = 32 > whenExhaustedAction = WHEN_EXHAUSTED_GROW > timeBetweenEvictionRunsMillis = 2 > minEvictableIdleTimeMillis = 6 > numTestsPerEvictionRun = -1 > The NullPointerException is thrown in the WHEN_EXHAUSTED_GROW branch of the > code. Specifically it appears that latch.getPool() returns null. > Any suggestions for a work-around would be appreciated. -- This message was sent by Atlassian Jira (v8.20.7#820007)
[jira] [Commented] (POOL-282) CLONE - Support AbandonedConfig in SharedPoolDataSource
[ https://issues.apache.org/jira/browse/POOL-282?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=17531165#comment-17531165 ] Gary D. Gregory commented on POOL-282: -- Hi [~psteitz] Any thoughts on [~ashok2ashok]'s questions? > CLONE - Support AbandonedConfig in SharedPoolDataSource > --- > > Key: POOL-282 > URL: https://issues.apache.org/jira/browse/POOL-282 > Project: Commons Pool > Issue Type: Improvement >Affects Versions: 2.0, 2.1, 2.2, 2.3 > Environment: Linux and Java 1.6 >Reporter: Michael Kerr >Priority: Minor > Labels: features > > BasicDataSource has support for AbandonedConfig > SharedPoolDataSource does not currently support reclaiming abandoned > connections. > It would be helpful if the user can extend the underlying connection pool to > add features like abandoned connection management. This is possible with > BasicDataSource. > Currently the only solution is to extend classes or replace classes in the > Apache package namespace. > Thanks for looking, > Michael -- This message was sent by Atlassian Jira (v8.20.7#820007)
[jira] [Updated] (DBCP-388) Support AbandonedConfig in SharedPoolDataSource
[ https://issues.apache.org/jira/browse/DBCP-388?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Gary D. Gregory updated DBCP-388: - Fix Version/s: (was: 2.4.1) > Support AbandonedConfig in SharedPoolDataSource > --- > > Key: DBCP-388 > URL: https://issues.apache.org/jira/browse/DBCP-388 > Project: Commons DBCP > Issue Type: Improvement >Affects Versions: 1.4 > Environment: Linux and Java 1.6 >Reporter: Michael Kerr >Priority: Minor > Labels: features > > BasicDataSource has support for AbandonedConfig > SharedPoolDataSource does not currently support reclaiming abandoned > connections. > It would be helpful if the user can extend the underlying connection pool to > add features like abandoned connection management. This is possible with > BasicDataSource. > Currently the only solution is to extend classes or replace classes in the > Apache package namespace. > Thanks for looking, > Michael -- This message was sent by Atlassian Jira (v8.20.7#820007)
[GitHub] [commons-dbcp] garydgregory commented on pull request #187: Bump jboss-logging from 3.4.3.Final to 3.5.0.Final
garydgregory commented on PR #187: URL: https://github.com/apache/commons-dbcp/pull/187#issuecomment-1115985779 Closing: Requires Java 11. -- 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. To unsubscribe, e-mail: issues-unsubscr...@commons.apache.org For queries about this service, please contact Infrastructure at: us...@infra.apache.org
[GitHub] [commons-dbcp] garydgregory closed pull request #187: Bump jboss-logging from 3.4.3.Final to 3.5.0.Final
garydgregory closed pull request #187: Bump jboss-logging from 3.4.3.Final to 3.5.0.Final URL: https://github.com/apache/commons-dbcp/pull/187 -- 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. To unsubscribe, e-mail: issues-unsubscr...@commons.apache.org For queries about this service, please contact Infrastructure at: us...@infra.apache.org
[GitHub] [commons-dbcp] dependabot[bot] commented on pull request #187: Bump jboss-logging from 3.4.3.Final to 3.5.0.Final
dependabot[bot] commented on PR #187: URL: https://github.com/apache/commons-dbcp/pull/187#issuecomment-1115985819 OK, I won't notify you again about this release, but will get in touch when a new version is available. If you'd rather skip all updates until the next major or minor version, let me know by commenting `@dependabot ignore this major version` or `@dependabot ignore this minor version`. You can also ignore all major, minor, or patch releases for a dependency by adding an [`ignore` condition](https://docs.github.com/en/code-security/supply-chain-security/configuration-options-for-dependency-updates#ignore) with the desired `update_types` to your config file. If you change your mind, just re-open this PR and I'll resolve any conflicts on it. -- 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. To unsubscribe, e-mail: issues-unsubscr...@commons.apache.org For queries about this service, please contact Infrastructure at: us...@infra.apache.org
[GitHub] [commons-daemon] markt-asf merged pull request #39: Fix for https://issues.redhat.com/browse/JBCS-1261
markt-asf merged PR #39: URL: https://github.com/apache/commons-daemon/pull/39 -- 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. To unsubscribe, e-mail: issues-unsubscr...@commons.apache.org For queries about this service, please contact Infrastructure at: us...@infra.apache.org
[jira] [Commented] (JEXL-367) Deprecate -> and support =>
[ https://issues.apache.org/jira/browse/JEXL-367?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=17531120#comment-17531120 ] Henri Biestro commented on JEXL-367: I'm sorry if my previous statement came out too strong; we are probably all in agreement. Again, as much as can be, I'll try and keep an opened mind when syntactic choices are made to be close (or identical) to JS. I don't hold any grudges against JS - besides the fact that it is a much too powerful language for scripting :) (imho: prototypes, this, classes are above scripting complexity necessities). [~hussachai] What are your other added features in your fork? (does not seem to be on GitHub, is it?). About JS, just realised that [Rhino|https://github.com/mozilla/rhino] is still alive ! ;) > Deprecate -> and support => > --- > > Key: JEXL-367 > URL: https://issues.apache.org/jira/browse/JEXL-367 > Project: Commons JEXL > Issue Type: Wish >Affects Versions: 3.2.1 >Reporter: Hussachai Puripunpinyo >Assignee: Henri Biestro >Priority: Major > > The JEXL code surprisingly looks a lot like Javascript. I think this change > is a good transition for folks to update the code, and it's pretty fine if > they can tolerate using the deprecate syntax and don't mind seeing a warning > log pop up every time. > I'd like to propose supporting => and deprecate ->. > The reasons are > - JavaScript becomes very popular and many people are familiar with it. > - JEXL is more like for a quick short script. In many scenarios, the target > audiences are not a programer. They often mistake a language as a JavaScript > (from my experience). > - JEXL syntax already looks a lot like JavaScript > -- var for variable declaration (Java added in Java 10, but JavaScript > supports this from the beginning) > -- The function keyword > -- Implicit type coercion > -- Ternary operator > The proposed change. > * Support => in addition to -> > * Deprecate -> and show a warning log when it's used. -- This message was sent by Atlassian Jira (v8.20.7#820007)
