[JBoss JIRA] (AG-136) Add a safe callback interface for pool events
by Luis Barreiro (Jira)
[ https://issues.redhat.com/browse/AG-136?page=com.atlassian.jira.plugin.sy... ]
Luis Barreiro resolved AG-136.
------------------------------
Resolution: Done
> Add a safe callback interface for pool events
> ---------------------------------------------
>
> Key: AG-136
> URL: https://issues.redhat.com/browse/AG-136
> Project: Agroal
> Issue Type: Feature Request
> Components: api, pool
> Affects Versions: 1.7
> Reporter: Luis Barreiro
> Assignee: Luis Barreiro
> Priority: Major
> Fix For: 1.8
>
>
> There is a need for a callback to intercept pool events that is safe for applications to use.
> Right now the current listener interface is fine for container implementations, but should not be used by higher level applications because:
> * The {{AgroalDataSourceListener}} interface was not designed with the Interceptor concept in mind. Agroal always invoke the listeners in the given order, so if there are 2 listeners with common concerns,only one of them will be effective.
> * The Listener gives access to the raw {{java.sql.Connection}} and therefore any error may cause chaos on the pool (leave an invalid connection on the pool, etc.)
> * Some methods on the listener are invoked by Agroal's own thread and therefore should not execute any long running task (that is not a problem in the context of this issue, but may be if we expose this interface as API)
> * When running Agroal with a TransactionManager, the life-cycle of the connections can be slightly different as this is associated with the transaction. This does not map well on the current listener interface.
> A new interface PoolInteceptor should be added to address this issues.
--
This message was sent by Atlassian Jira
(v7.13.8#713008)
6 years
[JBoss JIRA] (WFLY-13317) MicroProfile OpenTracing integration requires scope request
by Emmanuel Hugonnet (Jira)
Emmanuel Hugonnet created WFLY-13317:
----------------------------------------
Summary: MicroProfile OpenTracing integration requires scope request
Key: WFLY-13317
URL: https://issues.redhat.com/browse/WFLY-13317
Project: WildFly
Issue Type: Bug
Components: MP OpenTracing
Affects Versions: 19.0.0.Final
Reporter: Emmanuel Hugonnet
Assignee: Emmanuel Hugonnet
MicroProfile integration is using a ServletContext which requires requestScope to be active. When trying the MP Rest Client tck with WildFly this requirement creates the following failure:
org.jboss.weld.contexts.ContextNotActiveException: WELD-001303: No active contexts for scope type javax.enterprise.context.RequestScoped
at org.jboss.weld.core@3.1.3.Final//org.jboss.weld.manager.BeanManagerImpl.getContext(BeanManagerImpl.java:647)
at org.jboss.weld.core@3.1.3.Final//org.jboss.weld.bean.ContextualInstanceStrategy$DefaultContextualInstanceStrategy.getIfExists(ContextualInstanceStrategy.java:89)
at org.jboss.weld.core@3.1.3.Final//org.jboss.weld.bean.ContextualInstance.getIfExists(ContextualInstance.java:63)
at org.jboss.weld.core@3.1.3.Final//org.jboss.weld.bean.proxy.ContextBeanInstance.getInstance(ContextBeanInstance.java:87)
at org.jboss.weld.core@3.1.3.Final//org.jboss.weld.bean.proxy.ProxyMethodHandler.invoke(ProxyMethodHandler.java:105)
at org.jboss.weld.core(a)3.1.3.Final//org.jboss.weldx.servlet.ServletContext$$Proxy$_$$_WeldClientProxy.getAttribute(Unknown Source)
at org.wildfly.microprofile.opentracing-smallrye@20.0.0.Beta1-SNAPSHOT//org.wildfly.microprofile.opentracing.smallrye.TracerProducer.getTracer(TracerProducer.java:43)
--
This message was sent by Atlassian Jira
(v7.13.8#713008)
6 years
[JBoss JIRA] (WFLY-13293) When deploying "ROOT.war" in EAP7.x, the context root value output through jboss-cli is not valid
by Ricardo Martin Camarero (Jira)
[ https://issues.redhat.com/browse/WFLY-13293?page=com.atlassian.jira.plugi... ]
Ricardo Martin Camarero commented on WFLY-13293:
------------------------------------------------
[~flavia.rainone] [~brian.stansberry] I have been working on this trying to see other alternatives. The summary:
* The main problem is that the UndertowDeploymentInfoService.java right now changes the context path at the end [here|https://github.com/wildfly/wildfly/blob/master/undertow/src/main/jav...].
* So the UndertowDeploymentProcessor.java saves in the model and in the alias of the service an incorrect context path. That's why the jboss-cli shows an incorrect value and the root problem. In other parts of the code the context path saved in the model is used to recover the service using the alias.
The options I have been managing are the following two:
* The first solution I thought and what it's done in the PR. UndertowDeploymentProcessor.java just retrieves the Host service before and calculates the correct context path which is used for everything later (alias, model info, service,...). But there is no dependency over the host as Brian stated.
* Other option I have tried is just removing the alias for the service and use the real name which is obtained from the deploymentUnit (it's something like {{jboss.deployment.unit."app.war"}} or {{jboss.deployment.subunit."app.ear"."app.war"}} depending if it's in an ear or not). This means that several classes should also be modified, for example [JaxrsDeploymentDefinition|https://github.com/wildfly/wildfly/blob/master/...] or [DeploymentDefinition|https://github.com/wildfly/wildfly/blob/master/under...]. With this change the service name used is the real one, not the alias. This way the service can be the one that sets the context path in the model with the final value and it has a dependency over the Host. This is a big change, but it seems to work OK. Test pass at least. But I don't know if we can backport something like that (but that is another story).
Do you like more the second option? Do I prepare another PR and see if you think that is better?
> When deploying "ROOT.war" in EAP7.x, the context root value output through jboss-cli is not valid
> -------------------------------------------------------------------------------------------------
>
> Key: WFLY-13293
> URL: https://issues.redhat.com/browse/WFLY-13293
> Project: WildFly
> Issue Type: Bug
> Components: Web (Undertow)
> Affects Versions: 19.0.0.Final
> Reporter: Ricardo Martin Camarero
> Assignee: Ricardo Martin Camarero
> Priority: Major
>
> *When deploying "ROOT.war" default context-root is "/" even though i set a specific context-root in jboss-web.xml. However, If I check resources by jboss-cli, it seems like context-root value refers to jboss-web.xml and this value is invalid.*
> ROOT.war/WEB-INF/jboss-web.xml
> {code}
> <jboss-web version="7.0"
> xmlns:jboss="http://www.jboss.com/xml/ns/javaee"
> xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance"
> xsi:schemaLocation="http://www.jboss.com/xml/ns/javaee jboss-web_7_0.xsd">
> <context-root>/hello</context-root>
> </jboss-web>{code}
> {code}[standalone@192.168.122.1:10090 /] deployment-info
> NAME RUNTIME-NAME PERSISTENT ENABLED STATUS
> ROOT.war ROOT.war true true OK
> {code}
> server.log
> {code}
> 2020-03-24 10:35:56,344 INFO [org.wildfly.extension.undertow] (ServerService Thread Pool -- 78) WFLYUT0021: Registered web context: '/' for server 'default-server'
> 2020-03-24 10:35:56,354 INFO [org.jboss.as.server] (Controller Boot Thread) WFLYSRV0010: Deployed "ROOT.war" (runtime-name : "ROOT.war")
> {code}
> However, If I check resource by jboss-cli, it seems like context-root value refers to jboss-web.xml and this vaule is invalid.
> {code}
> [standalone@192.168.122.1:10090 /] /deployment=ROOT.war/subsystem=undertow:read-resource(include-runtime=true)
> {
> "outcome" => "success",
> "result" => {
> "active-sessions" => 0,
> "context-root" => "/hello", => this is invalid, the real value is "/"
> "expired-sessions" => 0,
> "highest-session-count" => 0,
> "max-active-sessions" => -1,
> "rejected-sessions" => 0,
> "server" => "default-server",
> "session-avg-alive-time" => 0,
> "session-max-alive-time" => 0,
> "sessions-created" => 0,
> "virtual-host" => "default-host",
> "servlet" => undefined,
> "websocket" => undefined
> }
> }
> {code}
> valid context-root is "/"
> {code}
> [hyoskim@hyoskim sophia]$ curl -v http://192.168.122.1:8180/test.jsp
> * About to connect() to 192.168.122.1 port 8180 (#0)
> * Trying 192.168.122.1...
> * Connected to 192.168.122.1 (192.168.122.1) port 8180 (#0)
> > GET /test.jsp HTTP/1.1
> > User-Agent: curl/7.29.0
> > Host: 192.168.122.1:8180
> > Accept: */*
> >
> < HTTP/1.1 200 OK
> < Connection: keep-alive
> < X-Powered-By: JSP/2.3
> < Set-Cookie: JSESSIONID=_Ej56uTEuy1B0U2Oi94pcVtCNwg7ngRNr7HO7TQ7.worker1; path=/
> < Content-Type: text/html;charset=ISO-8859-1
> < Content-Length: 6
> < Date: Tue, 24 Mar 2020 01:37:53 GMT
> <
> hello
> [hyoskim@hyoskim sophia]$ curl -v http://192.168.122.1:8180/hello/test.jsp
> * About to connect() to 192.168.122.1 port 8180 (#0)
> * Trying 192.168.122.1...
> * Connected to 192.168.122.1 (192.168.122.1) port 8180 (#0)
> > GET /hello/test.jsp HTTP/1.1
> > User-Agent: curl/7.29.0
> > Host: 192.168.122.1:8180
> > Accept: */*
> >
> < HTTP/1.1 404 Not Found
> < Connection: keep-alive
> < Content-Type: text/html;charset=UTF-8
> < Content-Length: 74
> < Date: Tue, 24 Mar 2020 01:37:23 GMT
> <
> * Connection #0 to host 192.168.122.1 left intact
> <html><head><title>Error</title></head><body>/hello/test.jsp</body></html>{code}
--
This message was sent by Atlassian Jira
(v7.13.8#713008)
6 years
[JBoss JIRA] (AG-136) Add a safe callback interface for pool events
by Luis Barreiro (Jira)
[ https://issues.redhat.com/browse/AG-136?page=com.atlassian.jira.plugin.sy... ]
Luis Barreiro commented on AG-136:
----------------------------------
Initially only acquire and return events will be available in this new interface. It was discussed that create and destroy were added as well, but the conclusion was that there is not enough interest in those events. They may be added in the future.
> Add a safe callback interface for pool events
> ---------------------------------------------
>
> Key: AG-136
> URL: https://issues.redhat.com/browse/AG-136
> Project: Agroal
> Issue Type: Feature Request
> Components: api, pool
> Affects Versions: 1.7
> Reporter: Luis Barreiro
> Assignee: Luis Barreiro
> Priority: Major
> Fix For: 1.8
>
>
> There is a need for a callback to intercept pool events that is safe for applications to use.
> Right now the current listener interface is fine for container implementations, but should not be used by higher level applications because:
> * The {{AgroalDataSourceListener}} interface was not designed with the Interceptor concept in mind. Agroal always invoke the listeners in the given order, so if there are 2 listeners with common concerns,only one of them will be effective.
> * The Listener gives access to the raw {{java.sql.Connection}} and therefore any error may cause chaos on the pool (leave an invalid connection on the pool, etc.)
> * Some methods on the listener are invoked by Agroal's own thread and therefore should not execute any long running task (that is not a problem in the context of this issue, but may be if we expose this interface as API)
> * When running Agroal with a TransactionManager, the life-cycle of the connections can be slightly different as this is associated with the transaction. This does not map well on the current listener interface.
> A new interface PoolInteceptor should be added to address this issues.
--
This message was sent by Atlassian Jira
(v7.13.8#713008)
6 years
[JBoss JIRA] (AG-136) Add a safe callback interface for pool events
by Luis Barreiro (Jira)
[ https://issues.redhat.com/browse/AG-136?page=com.atlassian.jira.plugin.sy... ]
Luis Barreiro updated AG-136:
-----------------------------
Description:
There is a need for a callback to intercept pool events that is safe for applications to use.
Right now the current listener interface is fine for container implementations, but should not be used by higher level applications because:
* The {{AgroalDataSourceListener}} interface was not designed with the Interceptor concept in mind. Agroal always invoke the listeners in the given order, so if there are 2 listeners with common concerns,only one of them will be effective.
* The Listener gives access to the raw {{java.sql.Connection}} and therefore any error may cause chaos on the pool (leave an invalid connection on the pool, etc.)
* Some methods on the listener are invoked by Agroal's own thread and therefore should not execute any long running task (that is not a problem in the context of this issue, but may be if we expose this interface as API)
* When running Agroal with a TransactionManager, the life-cycle of the connections can be slightly different as this is associated with the transaction. This does not map well on the current listener interface.
A new interface PoolInteceptor should be added to address this issues.
was:
There is a need for a callback to intercept pool events that is safe for applications to use.
Right now the current listener interface is fine for container implementations, but should not be used by higher level applications because:
* The ```AgroalDataSourceListener``` interface was not designed with the Interceptor concept in mind. Agroal always invoke the listeners in the given order, so if there are 2 listeners with common concerns,only one of them will be effective.
* The Listener gives access to the raw ```java.sql.Connection`` and therefore any error may cause chaos on the pool (leave an invalid connection on the pool, etc.)
* Some methods on the listener are invoked by Agroal's own thread and therefore should not execute any long running task (that is not a problem in the context of this issue, but may be if we expose this interface as API)
* When running Agroal with a TransactionManager, the life-cycle of the connections can be slightly different as this is associated with the transaction. This does not map well on the current listener interface.
> Add a safe callback interface for pool events
> ---------------------------------------------
>
> Key: AG-136
> URL: https://issues.redhat.com/browse/AG-136
> Project: Agroal
> Issue Type: Feature Request
> Components: api, pool
> Affects Versions: 1.7
> Reporter: Luis Barreiro
> Assignee: Luis Barreiro
> Priority: Major
> Fix For: 1.8
>
>
> There is a need for a callback to intercept pool events that is safe for applications to use.
> Right now the current listener interface is fine for container implementations, but should not be used by higher level applications because:
> * The {{AgroalDataSourceListener}} interface was not designed with the Interceptor concept in mind. Agroal always invoke the listeners in the given order, so if there are 2 listeners with common concerns,only one of them will be effective.
> * The Listener gives access to the raw {{java.sql.Connection}} and therefore any error may cause chaos on the pool (leave an invalid connection on the pool, etc.)
> * Some methods on the listener are invoked by Agroal's own thread and therefore should not execute any long running task (that is not a problem in the context of this issue, but may be if we expose this interface as API)
> * When running Agroal with a TransactionManager, the life-cycle of the connections can be slightly different as this is associated with the transaction. This does not map well on the current listener interface.
> A new interface PoolInteceptor should be added to address this issues.
--
This message was sent by Atlassian Jira
(v7.13.8#713008)
6 years
[JBoss JIRA] (AG-136) Add a safe callback interface for pool events
by Luis Barreiro (Jira)
Luis Barreiro created AG-136:
--------------------------------
Summary: Add a safe callback interface for pool events
Key: AG-136
URL: https://issues.redhat.com/browse/AG-136
Project: Agroal
Issue Type: Feature Request
Components: api, pool
Affects Versions: 1.7
Reporter: Luis Barreiro
Assignee: Luis Barreiro
Fix For: 1.8
There is a need for a callback to intercept pool events that is safe for applications to use.
Right now the current listener interface is fine for container implementations, but should not be used by higher level applications because:
* The ```AgroalDataSourceListener``` interface was not designed with the Interceptor concept in mind. Agroal always invoke the listeners in the given order, so if there are 2 listeners with common concerns,only one of them will be effective.
* The Listener gives access to the raw ```java.sql.Connection`` and therefore any error may cause chaos on the pool (leave an invalid connection on the pool, etc.)
* Some methods on the listener are invoked by Agroal's own thread and therefore should not execute any long running task (that is not a problem in the context of this issue, but may be if we expose this interface as API)
* When running Agroal with a TransactionManager, the life-cycle of the connections can be slightly different as this is associated with the transaction. This does not map well on the current listener interface.
--
This message was sent by Atlassian Jira
(v7.13.8#713008)
6 years
[JBoss JIRA] (WFCORE-4896) Support iteration over filtered cli query
by Brian Stansberry (Jira)
[ https://issues.redhat.com/browse/WFCORE-4896?page=com.atlassian.jira.plug... ]
Brian Stansberry updated WFCORE-4896:
-------------------------------------
Issue Type: Feature Request (was: Enhancement)
> Support iteration over filtered cli query
> -----------------------------------------
>
> Key: WFCORE-4896
> URL: https://issues.redhat.com/browse/WFCORE-4896
> Project: WildFly Core
> Issue Type: Feature Request
> Components: CLI, Management
> Reporter: Georg Tsakumagos
> Assignee: Jean Francois Denise
> Priority: Major
>
> It would be usefull to iterate over filtered queries in cli. I need to spare the only alowed level of if expression for the control flow inside the loop. I like to update all profiles containing elytron subsystem and to spare out all inherited profiles which include the base profiles.
> {code:java|title=CLI query example}
> for profile in /profile=*:query(select=[name], where=[includes=undefined])
> echo $profile
> done
> {code}
> {code:JSON|title=actual result}
> {"address" => [("profile" => "default")],"outcome" => "success","result" => {"name" => "default"}}
> {"address" => [("profile" => "ha")],"outcome" => "success","result" => {"name" => "ha"}}
> {"address" => [("profile" => "full")],"outcome" => "success","result" => {"name" => "full"}}
> {"address" => [("profile" => "full-ha")],"outcome" => "success","result" => {"name" => "full-ha"}}
> {"address" => [("profile" => "load-balancer")],"outcome" => "success","result" => {"name" => "load-balancer"}}
> {code}
> {code:java|title=desired result}
> default
> full
> full-ha
> gfi
> ha
> load-balancer
> {code}
> Maybe it would be a solution to extend the operation extend read-children-names by an property where to apply a filter.
> {code:JSON|title=extend read-children-names}
> for profile in /:read-children-names(child-type=profile,where=[includes=undefined])
> echo $profile
> done
> {code}
--
This message was sent by Atlassian Jira
(v7.13.8#713008)
6 years
[JBoss JIRA] (WFLY-13316) MicroProfile OpenTracing integration requires scope request
by Emmanuel Hugonnet (Jira)
Emmanuel Hugonnet created WFLY-13316:
----------------------------------------
Summary: MicroProfile OpenTracing integration requires scope request
Key: WFLY-13316
URL: https://issues.redhat.com/browse/WFLY-13316
Project: WildFly
Issue Type: Bug
Components: MP OpenTracing
Affects Versions: 19.0.0.Final
Reporter: Emmanuel Hugonnet
Assignee: Emmanuel Hugonnet
MicroProfile integration is using a ServletContext which requires requestScope to be active. When trying the MP Rest Client tck with WildFly this requirement creates the following failure:
org.jboss.weld.contexts.ContextNotActiveException: WELD-001303: No active contexts for scope type javax.enterprise.context.RequestScoped
at org.jboss.weld.core@3.1.3.Final//org.jboss.weld.manager.BeanManagerImpl.getContext(BeanManagerImpl.java:647)
at org.jboss.weld.core@3.1.3.Final//org.jboss.weld.bean.ContextualInstanceStrategy$DefaultContextualInstanceStrategy.getIfExists(ContextualInstanceStrategy.java:89)
at org.jboss.weld.core@3.1.3.Final//org.jboss.weld.bean.ContextualInstance.getIfExists(ContextualInstance.java:63)
at org.jboss.weld.core@3.1.3.Final//org.jboss.weld.bean.proxy.ContextBeanInstance.getInstance(ContextBeanInstance.java:87)
at org.jboss.weld.core@3.1.3.Final//org.jboss.weld.bean.proxy.ProxyMethodHandler.invoke(ProxyMethodHandler.java:105)
at org.jboss.weld.core(a)3.1.3.Final//org.jboss.weldx.servlet.ServletContext$$Proxy$_$$_WeldClientProxy.getAttribute(Unknown Source)
at org.wildfly.microprofile.opentracing-smallrye@20.0.0.Beta1-SNAPSHOT//org.wildfly.microprofile.opentracing.smallrye.TracerProducer.getTracer(TracerProducer.java:43)
--
This message was sent by Atlassian Jira
(v7.13.8#713008)
6 years
[JBoss JIRA] (WFCORE-4896) Support iteration over filtered cli query
by Georg Tsakumagos (Jira)
[ https://issues.redhat.com/browse/WFCORE-4896?page=com.atlassian.jira.plug... ]
Georg Tsakumagos updated WFCORE-4896:
-------------------------------------
Description:
It would be usefull to iterate over filtered queries in cli. I need to spare the only alowed level of if expression for the control flow inside the loop. I like to update all profiles containing elytron subsystem and to spare out all inherited profiles which include the base profiles.
{code:java|title=CLI query example}
for profile in /profile=*:query(select=[name], where=[includes=undefined])
echo $profile
done
{code}
{code:JSON|title=actual result}
{"address" => [("profile" => "default")],"outcome" => "success","result" => {"name" => "default"}}
{"address" => [("profile" => "ha")],"outcome" => "success","result" => {"name" => "ha"}}
{"address" => [("profile" => "full")],"outcome" => "success","result" => {"name" => "full"}}
{"address" => [("profile" => "full-ha")],"outcome" => "success","result" => {"name" => "full-ha"}}
{"address" => [("profile" => "load-balancer")],"outcome" => "success","result" => {"name" => "load-balancer"}}
{code}
{code:java|title=desired result}
default
full
full-ha
gfi
ha
load-balancer
{code}
Maybe it would be a solution to extend the operation extend read-children-names by an property where to apply a filter.
{code:JSON|title=extend read-children-names}
for profile in /:read-children-names(child-type=profile,where=[includes=undefined])
echo $profile
done
{code}
was:
It would be usefull to iterate over filtered queries in cli. I need to spare the only alowed level of if expression for the control foll inside the loop. I like to update all profiles containing elytron subsystem and to spare out all inherited profiles which include the base profiles.
{code:java|title=CLI query example}
for profile in /profile=*:query(select=[name], where=[includes=undefined])
echo $profile
done
{code}
{code:JSON|title=actual result}
{"address" => [("profile" => "default")],"outcome" => "success","result" => {"name" => "default"}}
{"address" => [("profile" => "ha")],"outcome" => "success","result" => {"name" => "ha"}}
{"address" => [("profile" => "full")],"outcome" => "success","result" => {"name" => "full"}}
{"address" => [("profile" => "full-ha")],"outcome" => "success","result" => {"name" => "full-ha"}}
{"address" => [("profile" => "load-balancer")],"outcome" => "success","result" => {"name" => "load-balancer"}}
{code}
{code:java|title=desired result}
default
full
full-ha
gfi
ha
load-balancer
{code}
Maybe it would be a solution to extend the operation extend read-children-names by an property where to apply a filter.
{code:JSON|title=extend read-children-names}
for profile in /:read-children-names(child-type=profile,where=[includes=undefined])
echo $profile
done
{code}
> Support iteration over filtered cli query
> -----------------------------------------
>
> Key: WFCORE-4896
> URL: https://issues.redhat.com/browse/WFCORE-4896
> Project: WildFly Core
> Issue Type: Enhancement
> Components: CLI, Management
> Reporter: Georg Tsakumagos
> Assignee: Jean Francois Denise
> Priority: Major
>
> It would be usefull to iterate over filtered queries in cli. I need to spare the only alowed level of if expression for the control flow inside the loop. I like to update all profiles containing elytron subsystem and to spare out all inherited profiles which include the base profiles.
> {code:java|title=CLI query example}
> for profile in /profile=*:query(select=[name], where=[includes=undefined])
> echo $profile
> done
> {code}
> {code:JSON|title=actual result}
> {"address" => [("profile" => "default")],"outcome" => "success","result" => {"name" => "default"}}
> {"address" => [("profile" => "ha")],"outcome" => "success","result" => {"name" => "ha"}}
> {"address" => [("profile" => "full")],"outcome" => "success","result" => {"name" => "full"}}
> {"address" => [("profile" => "full-ha")],"outcome" => "success","result" => {"name" => "full-ha"}}
> {"address" => [("profile" => "load-balancer")],"outcome" => "success","result" => {"name" => "load-balancer"}}
> {code}
> {code:java|title=desired result}
> default
> full
> full-ha
> gfi
> ha
> load-balancer
> {code}
> Maybe it would be a solution to extend the operation extend read-children-names by an property where to apply a filter.
> {code:JSON|title=extend read-children-names}
> for profile in /:read-children-names(child-type=profile,where=[includes=undefined])
> echo $profile
> done
> {code}
--
This message was sent by Atlassian Jira
(v7.13.8#713008)
6 years