[JBoss JIRA] (DROOLS-5387) Rule Names are not converted GDST <-> XLS
by Jozef Marko (Jira)
[ https://issues.redhat.com/browse/DROOLS-5387?page=com.atlassian.jira.plug... ]
Jozef Marko updated DROOLS-5387:
--------------------------------
Summary: Rule Names are not converted GDST <-> XLS (was: Rule Names are converted GDST <-> XLS)
> Rule Names are not converted GDST <-> XLS
> -----------------------------------------
>
> Key: DROOLS-5387
> URL: https://issues.redhat.com/browse/DROOLS-5387
> Project: Drools
> Issue Type: Bug
> Components: Guided Decision Table Editor, XLS Decision Table Editor
> Affects Versions: 7.39.0.Final
> Reporter: Jozef Marko
> Assignee: Toni Rikkola
> Priority: Major
> Labels: drools-tools
>
> After DROOLS-5333 we should ensure custom rule names are correctly converted in both ways GDST->XLS and XLS->GDST.
> Currently even if in GDST we declared custom rule names in the converted XLS are used some autogonerated values as [tablename_rowindex].
--
This message was sent by Atlassian Jira
(v7.13.8#713008)
5 years, 5 months
[JBoss JIRA] (WFLY-13639) Avoid duplicate expiration scheduling on member leave for non-tx invalidation cache
by Paul Ferraro (Jira)
[ https://issues.redhat.com/browse/WFLY-13639?page=com.atlassian.jira.plugi... ]
Paul Ferraro updated WFLY-13639:
--------------------------------
Description:
Following WFLY-13627, a non-tx invalidation cache will schedule session/SFSB expiration on the local member. When that member leaves, the expiration will be reschedule on the primary owner of segment 0 (in a non-tx cache, all entries map to segment 0). However, since that member cannot distinguish which sessions/SFSBs were owned by the leaving member, it must schedule all sessions/SFSBs.
By storing the address of the member that handled a given request along with a web session/SFSBs metadata, we can discriminate which entries require expiration rescheduling on topology change for non-tx invalidation caches.
was:By storing the address of the member that handled a given request along with a web session/SFSBs metadata, we can discriminate which entries require expiration rescheduling on topology change for non-tx invalidation caches.
> Avoid duplicate expiration scheduling on member leave for non-tx invalidation cache
> -----------------------------------------------------------------------------------
>
> Key: WFLY-13639
> URL: https://issues.redhat.com/browse/WFLY-13639
> Project: WildFly
> Issue Type: Bug
> Components: Clustering
> Affects Versions: 20.0.0.Final
> Reporter: Paul Ferraro
> Assignee: Paul Ferraro
> Priority: Major
>
> Following WFLY-13627, a non-tx invalidation cache will schedule session/SFSB expiration on the local member. When that member leaves, the expiration will be reschedule on the primary owner of segment 0 (in a non-tx cache, all entries map to segment 0). However, since that member cannot distinguish which sessions/SFSBs were owned by the leaving member, it must schedule all sessions/SFSBs.
> By storing the address of the member that handled a given request along with a web session/SFSBs metadata, we can discriminate which entries require expiration rescheduling on topology change for non-tx invalidation caches.
--
This message was sent by Atlassian Jira
(v7.13.8#713008)
5 years, 5 months
[JBoss JIRA] (WFLY-13639) Avoid duplicate expiration scheduling on member leave for non-tx invalidation cache
by Paul Ferraro (Jira)
Paul Ferraro created WFLY-13639:
-----------------------------------
Summary: Avoid duplicate expiration scheduling on member leave for non-tx invalidation cache
Key: WFLY-13639
URL: https://issues.redhat.com/browse/WFLY-13639
Project: WildFly
Issue Type: Bug
Components: Clustering
Affects Versions: 20.0.0.Final
Reporter: Paul Ferraro
Assignee: Paul Ferraro
By storing the address of the member that handled a given request along with a web session/SFSBs metadata, we can discriminate which entries require expiration rescheduling on topology change for non-tx invalidation caches.
--
This message was sent by Atlassian Jira
(v7.13.8#713008)
5 years, 5 months
[JBoss JIRA] (WFLY-13638) Permit multiples applications to the same server registry a MP openapi endpoint
by Rhuan Rocha (Jira)
[ https://issues.redhat.com/browse/WFLY-13638?page=com.atlassian.jira.plugi... ]
Rhuan Rocha updated WFLY-13638:
-------------------------------
Description:
In the Wildfly 20, if I deploy two applications in the same server just one registry an openapi endpoint. Look at this code:
[https://github.com/wildfly/wildfly/blob/501c916b14663d328582a6625e9d492c2...]
It makes sense as the endpoint is registered to http://{host}:\{port}/openpi, but I think it is better to registry it considering the context root. With this, we can registry multiples openapi per server. Thus the openapi endpoint can be registered to http://{host}:\{port}/\{context-root}/openapi. Looking at the code looks like it is possible to be done. If we have access to the information of context-root in [https://github.com/wildfly/wildfly/blob/501c916b14663d328582a6625e9d4..., then we can start it considering the context-root. I think it will be a very common scenario of use and it will be very helpful to users.
was:
In the Wildfly 20, if I deploy two applications in the same server just one registry an openapi endpoint. Look at this code:
[https://github.com/wildfly/wildfly/blob/501c916b14663d328582a6625e9d492c2...]
It makes sense as the endpoint is registered to http://{host}:\{port}/openpi, but I think it is better to registry it considering the context root. With this, we can registry multiples openapi per server. Thus the openapi endpoint can be registered to http://{host}:\{port}/\{context-root}/openapi. Looking at the code looks like it is possible to be done. If we have access to the information of context-root in [https://github.com/wildfly/wildfly/blob/501c916b14663d328582a6625e9d4..., then we can start it in considering the context-root. I think it will be a very common scenario of use and it will be very helpful to users.
> Permit multiples applications to the same server registry a MP openapi endpoint
> -------------------------------------------------------------------------------
>
> Key: WFLY-13638
> URL: https://issues.redhat.com/browse/WFLY-13638
> Project: WildFly
> Issue Type: Feature Request
> Components: MP OpenAPI
> Affects Versions: 20.0.0.Final
> Reporter: Rhuan Rocha
> Assignee: Paul Ferraro
> Priority: Major
>
> In the Wildfly 20, if I deploy two applications in the same server just one registry an openapi endpoint. Look at this code:
> [https://github.com/wildfly/wildfly/blob/501c916b14663d328582a6625e9d492c2...]
>
> It makes sense as the endpoint is registered to http://{host}:\{port}/openpi, but I think it is better to registry it considering the context root. With this, we can registry multiples openapi per server. Thus the openapi endpoint can be registered to http://{host}:\{port}/\{context-root}/openapi. Looking at the code looks like it is possible to be done. If we have access to the information of context-root in [https://github.com/wildfly/wildfly/blob/501c916b14663d328582a6625e9d4..., then we can start it considering the context-root. I think it will be a very common scenario of use and it will be very helpful to users.
--
This message was sent by Atlassian Jira
(v7.13.8#713008)
5 years, 5 months
[JBoss JIRA] (WFLY-13638) Permit multiples applications to the same server registry a MP openapi endpoint
by Rhuan Rocha (Jira)
[ https://issues.redhat.com/browse/WFLY-13638?page=com.atlassian.jira.plugi... ]
Rhuan Rocha updated WFLY-13638:
-------------------------------
Description:
In the Wildfly 20, if I deploy two applications in the same server just one registry an openapi endpoint. Look at this code:
[https://github.com/wildfly/wildfly/blob/501c916b14663d328582a6625e9d492c2...]
It makes sense as the endpoint is registered to http://{host}:\{port}/openpi, but I think it is better to registry it considering the context root. With this, we can registry multiples openapi per server. Thus the openapi endpoint can be registered to http://{host}:\{port}/\{context-root}/openapi. Looking at the code looks like it is possible to be done. If we have access to the information of context-root in [https://github.com/wildfly/wildfly/blob/501c916b14663d328582a6625e9d4..., then we can start it in considering the context-root. I think it will be a very common scenario of use and it will be very helpful to users.
was:
In the Wildfly 20, if I deploy two applications in the same server just one registry an openapi endpoint. Look at this code:
[https://github.com/wildfly/wildfly/blob/501c916b14663d328582a6625e9d492c2...]
It makes sense as the endpoint is registered to _http://{host}:\{port}/openpi_, but I think it is better to registry it considering the context root. With this, we can registry multiples openapi per server. Thus the openapi endpoint can be registered to _http://{host}:\{port}/\{context-root}/openapi._ Looking at the code looks like it is possible to be done. If we have access to the information of context-root in [https://github.com/wildfly/wildfly/blob/501c916b14663d328582a6625e9d4..., then we can start it in considering the context-root. I think it will be a very common scenario of use and it will be very helpful to users.
> Permit multiples applications to the same server registry a MP openapi endpoint
> -------------------------------------------------------------------------------
>
> Key: WFLY-13638
> URL: https://issues.redhat.com/browse/WFLY-13638
> Project: WildFly
> Issue Type: Feature Request
> Components: MP OpenAPI
> Affects Versions: 20.0.0.Final
> Reporter: Rhuan Rocha
> Assignee: Paul Ferraro
> Priority: Major
>
> In the Wildfly 20, if I deploy two applications in the same server just one registry an openapi endpoint. Look at this code:
> [https://github.com/wildfly/wildfly/blob/501c916b14663d328582a6625e9d492c2...]
>
> It makes sense as the endpoint is registered to http://{host}:\{port}/openpi, but I think it is better to registry it considering the context root. With this, we can registry multiples openapi per server. Thus the openapi endpoint can be registered to http://{host}:\{port}/\{context-root}/openapi. Looking at the code looks like it is possible to be done. If we have access to the information of context-root in [https://github.com/wildfly/wildfly/blob/501c916b14663d328582a6625e9d4..., then we can start it in considering the context-root. I think it will be a very common scenario of use and it will be very helpful to users.
--
This message was sent by Atlassian Jira
(v7.13.8#713008)
5 years, 5 months
[JBoss JIRA] (WFLY-13638) Permit multiples applications to the same server registry a MP openapi endpoint
by Rhuan Rocha (Jira)
[ https://issues.redhat.com/browse/WFLY-13638?page=com.atlassian.jira.plugi... ]
Rhuan Rocha updated WFLY-13638:
-------------------------------
Description:
In the Wildfly 20, if I deploy two applications in the same server just one registry an openapi endpoint. Look at this code:
[https://github.com/wildfly/wildfly/blob/501c916b14663d328582a6625e9d492c2...]
It makes sense as the endpoint is registered to _http://{host}:\{port}/openpi_, but I think it is better to registry it considering the context root. With this, we can registry multiples openapi per server. Thus the openapi endpoint can be registered to _http://{host}:\{port}/\{context-root}/openapi._ Looking at the code looks like it is possible to be done. If we have access to the information of context-root in [https://github.com/wildfly/wildfly/blob/501c916b14663d328582a6625e9d4..., then we can start it in considering the context-root. I think it will be a very common scenario of use and it will be very helpful to users.
was:
In the Wildfly 20, if I deploy two application in the same server just one registry an openapi endpoint. Look at this code:
[https://github.com/wildfly/wildfly/blob/501c916b14663d328582a6625e9d492c2...]
It makes sense as the endpoint is registered to _http://{host}:\{port}/openpi_, but I think it is better to registry it considering the context root. With this, we can registry multiples openapi per server. Thus the openapi endpoint can be registered to _http://{host}:\{port}/\{context-root}/openapi._ Looking at the code looks like it is possible to be done. If we have access to the information of context-root in [https://github.com/wildfly/wildfly/blob/501c916b14663d328582a6625e9d4..., then we can start it in considering the context-root. I think it will be a very common scenario of use and it will be very helpful to users.
> Permit multiples applications to the same server registry a MP openapi endpoint
> -------------------------------------------------------------------------------
>
> Key: WFLY-13638
> URL: https://issues.redhat.com/browse/WFLY-13638
> Project: WildFly
> Issue Type: Feature Request
> Components: MP OpenAPI
> Affects Versions: 20.0.0.Final
> Reporter: Rhuan Rocha
> Assignee: Paul Ferraro
> Priority: Major
>
> In the Wildfly 20, if I deploy two applications in the same server just one registry an openapi endpoint. Look at this code:
> [https://github.com/wildfly/wildfly/blob/501c916b14663d328582a6625e9d492c2...]
>
> It makes sense as the endpoint is registered to _http://{host}:\{port}/openpi_, but I think it is better to registry it considering the context root. With this, we can registry multiples openapi per server. Thus the openapi endpoint can be registered to _http://{host}:\{port}/\{context-root}/openapi._ Looking at the code looks like it is possible to be done. If we have access to the information of context-root in [https://github.com/wildfly/wildfly/blob/501c916b14663d328582a6625e9d4..., then we can start it in considering the context-root. I think it will be a very common scenario of use and it will be very helpful to users.
--
This message was sent by Atlassian Jira
(v7.13.8#713008)
5 years, 5 months
[JBoss JIRA] (WFLY-13638) Permit multiples applications to the same server registry a MP openapi endpoint
by Rhuan Rocha (Jira)
[ https://issues.redhat.com/browse/WFLY-13638?page=com.atlassian.jira.plugi... ]
Rhuan Rocha updated WFLY-13638:
-------------------------------
Description:
In the Wildfly 20, if I deploy two application in the same server just one registry an openapi endpoint. Look at this code:
[https://github.com/wildfly/wildfly/blob/501c916b14663d328582a6625e9d492c2...]
It makes sense as the endpoint is registered to _http://{host}:\{port}/openpi_, but I think it is better to registry it considering the context root. With this, we can registry multiples openapi per server. Thus the openapi endpoint can be registered to _http://{host}:\{port}/\{context-root}/openapi._ Looking at the code looks like it is possible to be done. If we have access to the information of context-root in [https://github.com/wildfly/wildfly/blob/501c916b14663d328582a6625e9d4..., then we can start it in considering the context-root. I think it will be a very common scenario of use and it will be very helpful to users.
was:
In the Wildfly 20, if I deploy two application in the same server just one registry an openapi endpoint. Look at this code:
[https://github.com/wildfly/wildfly/blob/501c916b14663d328582a6625e9d492c2...]
It makes sense as the endpoint is registered to _http://\{host}:\{port}/openpi_, but I think it is better to registry it considering the context root. With this, we can registry multiples openapi per server. Thus the openapi endpoint can be registered to _http://\{host}:\{port}/\{context-root}/openapi._ Looking at the code looks like it is possible to be done. If we have access to the information of context-root in [https://github.com/wildfly/wildfly/blob/501c916b14663d328582a6625e9d4..., then we can start it in considering the context-root. I think it will be a very common scenario of use and it will be very helpful to users.
> Permit multiples applications to the same server registry a MP openapi endpoint
> -------------------------------------------------------------------------------
>
> Key: WFLY-13638
> URL: https://issues.redhat.com/browse/WFLY-13638
> Project: WildFly
> Issue Type: Feature Request
> Components: MP OpenAPI
> Affects Versions: 20.0.0.Final
> Reporter: Rhuan Rocha
> Assignee: Paul Ferraro
> Priority: Major
>
> In the Wildfly 20, if I deploy two application in the same server just one registry an openapi endpoint. Look at this code:
> [https://github.com/wildfly/wildfly/blob/501c916b14663d328582a6625e9d492c2...]
>
> It makes sense as the endpoint is registered to _http://{host}:\{port}/openpi_, but I think it is better to registry it considering the context root. With this, we can registry multiples openapi per server. Thus the openapi endpoint can be registered to _http://{host}:\{port}/\{context-root}/openapi._ Looking at the code looks like it is possible to be done. If we have access to the information of context-root in [https://github.com/wildfly/wildfly/blob/501c916b14663d328582a6625e9d4..., then we can start it in considering the context-root. I think it will be a very common scenario of use and it will be very helpful to users.
--
This message was sent by Atlassian Jira
(v7.13.8#713008)
5 years, 5 months
[JBoss JIRA] (WFLY-13638) Permit multiples applications to the same server registry a MP openapi endpoint
by Rhuan Rocha (Jira)
[ https://issues.redhat.com/browse/WFLY-13638?page=com.atlassian.jira.plugi... ]
Rhuan Rocha updated WFLY-13638:
-------------------------------
Description:
In the Wildfly 20, if I deploy two application in the same server just one registry an openapi endpoint. Look at this code:
[https://github.com/wildfly/wildfly/blob/501c916b14663d328582a6625e9d492c2...]
It makes sense as the endpoint is registered to _http://\{host}:\{port}/openpi_, but I think it is better to registry it considering the context root. With this, we can registry multiples openapi per server. Thus the openapi endpoint can be registered to _http://\{host}:\{port}/\{context-root}/openapi._ Looking at the code looks like it is possible to be done. If we have access to the information of context-root in [https://github.com/wildfly/wildfly/blob/501c916b14663d328582a6625e9d4..., then we can start it in considering the context-root. I think it will be a very common scenario of use and it will be very helpful to users.
was:
In the Wildfly 20, if I deploys two application in the same server just one registries an openapi endpoint. Look at this code:
[https://github.com/wildfly/wildfly/blob/501c916b14663d328582a6625e9d492c2...]
It makes sense as the endpoint is registered to _http://\{host}:\{port}/openpi_, but I think it is better to registry it considering the context root. With this, we can registry multiples openapi per server. Thus the openapi endpoint can be registered to _http://\{host}:\{port}/\{context-root}/openapi._ Looking at the code looks like it is possible to be done. If we have access to the information of context-root in [https://github.com/wildfly/wildfly/blob/501c916b14663d328582a6625e9d4..., then we can start it in considering the context-root. I think it will be a very common scenario of use and it will be very helpful to users.
> Permit multiples applications to the same server registry a MP openapi endpoint
> -------------------------------------------------------------------------------
>
> Key: WFLY-13638
> URL: https://issues.redhat.com/browse/WFLY-13638
> Project: WildFly
> Issue Type: Feature Request
> Components: MP OpenAPI
> Affects Versions: 20.0.0.Final
> Reporter: Rhuan Rocha
> Assignee: Paul Ferraro
> Priority: Major
>
> In the Wildfly 20, if I deploy two application in the same server just one registry an openapi endpoint. Look at this code:
> [https://github.com/wildfly/wildfly/blob/501c916b14663d328582a6625e9d492c2...]
>
> It makes sense as the endpoint is registered to _http://\{host}:\{port}/openpi_, but I think it is better to registry it considering the context root. With this, we can registry multiples openapi per server. Thus the openapi endpoint can be registered to _http://\{host}:\{port}/\{context-root}/openapi._ Looking at the code looks like it is possible to be done. If we have access to the information of context-root in [https://github.com/wildfly/wildfly/blob/501c916b14663d328582a6625e9d4..., then we can start it in considering the context-root. I think it will be a very common scenario of use and it will be very helpful to users.
--
This message was sent by Atlassian Jira
(v7.13.8#713008)
5 years, 5 months