[JBoss JIRA] (DROOLS-4409) [DMN Designer] Data Type Structure update is slow
by Jozef Marko (Jira)
Jozef Marko created DROOLS-4409:
-----------------------------------
Summary: [DMN Designer] Data Type Structure update is slow
Key: DROOLS-4409
URL: https://issues.jboss.org/browse/DROOLS-4409
Project: Drools
Issue Type: Bug
Components: DMN Editor
Affects Versions: 7.25.0.Final
Reporter: Jozef Marko
Assignee: Michael Anstis
Attachments: data-type-structure-edit.webm, structures.zip
The performance of dmn structures edit seems to be downgraded. Just adding another field into a existing structure takes ~5 seconds. The attached video demonstrates just saving added field however also other operations, like remove field performance was downgraded.
--
This message was sent by Atlassian Jira
(v7.12.1#712002)
6 years, 9 months
[JBoss JIRA] (WFLY-12300) Convert to Jakarta EE 8 specification APIs
by Scott Marlow (Jira)
[ https://issues.jboss.org/browse/WFLY-12300?page=com.atlassian.jira.plugin... ]
Scott Marlow updated WFLY-12300:
--------------------------------
Description:
This is a top-level task for moving WildFly to specification API artifacts associated with Jakarta EE 8.
The Jakarta EE 8 spec APIs are meant to be fully compatible with their Java EE 8 analogues, so this is not expected to result in runtime behavioral differences.
I don't anticipate code changes specific to this top level task. Instead changes will be associated with other issues linked to this one.
The overall goal is to use API jars that either directly come from the Jakarta EE projects, or that use code closely based on those projects; i.e. that are forks derived from the Jakarta EE code that incorporate jboss.org specific changes and whose maintainers monitor the Jakarta EE projects and bring over needed changes and contribute any relevant jboss.org changes back.
For each JBoss specification API fork that existed in EAP 7.2, a designated owner for that API jar has been determined. The task for each owner consists of:
# Create/update a jboss.org Jakarta fork.
# Track work on that fork via issues in the https://issues.jboss.org/projects/JBEE JIRA project. If there is a high-level issue for that fork, the component owner *should* link it to this issue via a 'relates to' link.
# For the fork, the component owner *must* create a WFLY or WFCORE JIRA to track the change of the WildFly code to use the Jarkarta EE based artifact. That can either be a subtask of this task, or a separate issue linked to this once such that that issue is 'incorporated by' this one. That JIRA should have priority 'Critical' and should have its Fix Version set to 18.0.0.Final or 10.0.0.Final for WFCORE.
Generally, WildFly and WildFly Core do not accept non-Final artifacts into their master branch. For projects that we are forking from the Jakarta EE projects, we are making an exception to this rule:
_Once a Jakarta API project has made a staging release and submitted the specification for formal approval, it is acceptable for the jboss.org fork of that project to produce a CR release based on the code in that staged release and ask that it be incorporated into master._
_In fact, doing this is strongly encouraged as it allows us to further verify the fork._
Once the staged release is approved, the component owner *must* as soon as possible (e.g. the next working day) produce a .Final artifact from the fork and submit a component upgrade PR.
For artifacts that will not involve a fork (e.g. JPA), the component owner should plan to file a PR moving to the Jakarta artifact (e.g. jakarta.persistence:jakarta.persistence-api) as soon as the official version after Jakarta is available in maven central (after Jakarta EE 8 final release).
Following are the relevant APIs, organized by the maven GA of the artifact produced by the Jakarta project, along with the 'owner' of that component:
||API||Owner||
|jakarta.annotation:jakarta.annotation-api|Yeray Borges|
|jakarta.batch:jakarta.batch-api|Cheng Fang|
|jakarta.ejb:jakarta.ejb-api|Cheng Fang/Tomasz Adamski|
|jakarta.el:jakarta.el-api|Scott Marlow|
|jakarta.enterprise.concurrent:jakarta.enterprise.concurrent-api|Eduardo Martins|
|jakarta.faces:jakarta.faces-api|Farah Juma|
|jakarta.interceptor:jakarta.interceptor-api|Yeray Borges|
|jakarta.jms:jakarta.jms-api|Emmanuel Hugonnet|
|jakarta.management.j2ee:jakarta.management.j2ee-api|Jeff Mesnil|
|jakarta.resource:jakarta.resource-api|Stefano Maestri|
|jakarta.security.auth.message:jakarta.security.auth.message-api|Darran Lofthouse / Farah Juma|
|jakarta.security.jacc:jakarta.security.jacc-api|Darran Lofthouse / Farah Juma|
|jakarta.servlet:jakarta.servlet-api|Flavia Rainone|
|jakarta.servlet.jsp:jakarta.servlet.jsp-api|Flavia Rainone|
|jakarta.transaction:jakarta.transaction-api|Tom Jenkinson|
|jakarta.websocket:jakarta.websocket-all|Flavia Rainone|
|jakarta.ws.rs:jakarta.ws.rs-api|Ron Sigal|
|jakarta.xml.bind:jakarta.xml.bind-api|Jim Ma|
|jakarta.xml.rpc:jakarta.xml.rpc-api|Jim Ma|
|jakarta.xml.soap:jakarta.xml.soap-api|Jim Ma|
|jakarta.xml.ws:jakarta.xml.ws-api|Jim Ma|
was:
This is a top-level task for moving WildFly to specification API artifacts associated with Jakarta EE 8.
The Jakarta EE 8 spec APIs are meant to be fully compatible with their Java EE 8 analogues, so this is not expected to result in runtime behavioral differences.
I don't anticipate code changes specific to this top level task. Instead changes will be associated with other issues linked to this one.
The overall goal is to use API jars that either directly come from the Jakarta EE projects, or that use code closely based on those projects; i.e. that are forks derived from the Jakarta EE code that incorporate jboss.org specific changes and whose maintainers monitor the Jakarta EE projects and bring over needed changes and contribute any relevant jboss.org changes back.
For each JBoss specification API fork that existed in EAP 7.2, a designated owner for that API jar has been determined. The task for each owner consists of:
# Create/update a jboss.org Jakarta fork.
# Track work on that fork via issues in the https://issues.jboss.org/projects/JBEE JIRA project. If there is a high-level issue for that fork, the component owner *should* link it to this issue via a 'relates to' link.
# For the fork, the component owner *must* create a WFLY or WFCORE JIRA to track the change of the WildFly code to use the Jarkarta EE based artifact. That can either be a subtask of this task, or a separate issue linked to this once such that that issue is 'incorporated by' this one. That JIRA should have priority 'Critical' and should have its Fix Version set to 18.0.0.Final or 10.0.0.Final for WFCORE.
Generally, WildFly and WildFly Core do not accept non-Final artifacts into their master branch. For projects that we are forking from the Jakarta EE projects, we are making an exception to this rule:
_Once a Jakarta API project has made a staging release and submitted the specification for formal approval, it is acceptable for the jboss.org fork of that project to produce a CR release based on the code in that staged release and ask that it be incorporated into master._
_In fact, doing this is strongly encouraged as it allows us to further verify the fork._
Once the staged release is approved, the component owner *must* as soon as possible (e.g. the next working day) produce a .Final artifact from the fork and submit a component upgrade PR.
For artifacts that will not involve a fork (e.g. JPA), the component owner should plan to file a PR moving to the Jakarta artifact (e.g. jakarta.persistence:jakarta.persistence-api) as soon as the official version after Jakarta is available in maven central (after Jakarta EE 8 final release).
Following are the relevant APIs, organized by the maven GA of the artifact produced by the Jakarta project, along with the 'owner' of that component:
||API||Owner||
|jakarta.annotation:jakarta.annotation-api|Yeray Borges|
|jakarta.batch:jakarta.batch-api|Cheng Fang|
|jakarta.ejb:jakarta.ejb-api|Cheng Fang/Tomasz Adamski|
|jakarta.el:jakarta.el-api|Scott Marlow|
|jakarta.enterprise:jakarta.enterprise.cdi-spec|Matej Novotny|
|jakarta.enterprise.concurrent:jakarta.enterprise.concurrent-api|Eduardo Martins|
|jakarta.faces:jakarta.faces-api|Farah Juma|
|jakarta.interceptor:jakarta.interceptor-api|Yeray Borges|
|jakarta.jms:jakarta.jms-api|Emmanuel Hugonnet|
|jakarta.json:jakarta.json-api|James Perkins|
|jakarta.json.bind:jakarta.json.bind-api|James Perkins|
|jakarta.management.j2ee:jakarta.management.j2ee-api|Jeff Mesnil|
|jakarta.persistence:jakarta.persistence-api|Scott Marlow|
|jakarta.resource:jakarta.resource-api|Stefano Maestri|
|jakarta.security.auth.message:jakarta.security.auth.message-api|Darran Lofthouse / Farah Juma|
|jakarta.security.jacc:jakarta.security.jacc-api|Darran Lofthouse / Farah Juma|
|jakarta.servlet:jakarta.servlet-api|Flavia Rainone|
|jakarta.servlet.jsp:jakarta.servlet.jsp-api|Flavia Rainone|
|jakarta.servlet.jsp.jstl:jakarta.servlet.jsp.jstl-api|Flavia Rainone|
|jakarta.transaction:jakarta.transaction-api|Tom Jenkinson|
|jakarta.validation:jakarta.validation-api|Brian Stansberry|
|jakarta.websocket:jakarta.websocket-all|Flavia Rainone|
|jakarta.ws.rs:jakarta.ws.rs-api|Ron Sigal|
|jakarta.xml.bind:jakarta.xml.bind-api|Jim Ma|
|jakarta.xml.rpc:jakarta.xml.rpc-api|Jim Ma|
|jakarta.xml.soap:jakarta.xml.soap-api|Jim Ma|
|jakarta.xml.ws:jakarta.xml.ws-api|Jim Ma|
> Convert to Jakarta EE 8 specification APIs
> ------------------------------------------
>
> Key: WFLY-12300
> URL: https://issues.jboss.org/browse/WFLY-12300
> Project: WildFly
> Issue Type: Task
> Components: Server
> Reporter: Brian Stansberry
> Assignee: Scott Marlow
> Priority: Critical
> Fix For: 18.0.0.Final
>
>
> This is a top-level task for moving WildFly to specification API artifacts associated with Jakarta EE 8.
> The Jakarta EE 8 spec APIs are meant to be fully compatible with their Java EE 8 analogues, so this is not expected to result in runtime behavioral differences.
> I don't anticipate code changes specific to this top level task. Instead changes will be associated with other issues linked to this one.
> The overall goal is to use API jars that either directly come from the Jakarta EE projects, or that use code closely based on those projects; i.e. that are forks derived from the Jakarta EE code that incorporate jboss.org specific changes and whose maintainers monitor the Jakarta EE projects and bring over needed changes and contribute any relevant jboss.org changes back.
> For each JBoss specification API fork that existed in EAP 7.2, a designated owner for that API jar has been determined. The task for each owner consists of:
> # Create/update a jboss.org Jakarta fork.
> # Track work on that fork via issues in the https://issues.jboss.org/projects/JBEE JIRA project. If there is a high-level issue for that fork, the component owner *should* link it to this issue via a 'relates to' link.
> # For the fork, the component owner *must* create a WFLY or WFCORE JIRA to track the change of the WildFly code to use the Jarkarta EE based artifact. That can either be a subtask of this task, or a separate issue linked to this once such that that issue is 'incorporated by' this one. That JIRA should have priority 'Critical' and should have its Fix Version set to 18.0.0.Final or 10.0.0.Final for WFCORE.
> Generally, WildFly and WildFly Core do not accept non-Final artifacts into their master branch. For projects that we are forking from the Jakarta EE projects, we are making an exception to this rule:
> _Once a Jakarta API project has made a staging release and submitted the specification for formal approval, it is acceptable for the jboss.org fork of that project to produce a CR release based on the code in that staged release and ask that it be incorporated into master._
> _In fact, doing this is strongly encouraged as it allows us to further verify the fork._
> Once the staged release is approved, the component owner *must* as soon as possible (e.g. the next working day) produce a .Final artifact from the fork and submit a component upgrade PR.
> For artifacts that will not involve a fork (e.g. JPA), the component owner should plan to file a PR moving to the Jakarta artifact (e.g. jakarta.persistence:jakarta.persistence-api) as soon as the official version after Jakarta is available in maven central (after Jakarta EE 8 final release).
> Following are the relevant APIs, organized by the maven GA of the artifact produced by the Jakarta project, along with the 'owner' of that component:
> ||API||Owner||
> |jakarta.annotation:jakarta.annotation-api|Yeray Borges|
> |jakarta.batch:jakarta.batch-api|Cheng Fang|
> |jakarta.ejb:jakarta.ejb-api|Cheng Fang/Tomasz Adamski|
> |jakarta.el:jakarta.el-api|Scott Marlow|
> |jakarta.enterprise.concurrent:jakarta.enterprise.concurrent-api|Eduardo Martins|
> |jakarta.faces:jakarta.faces-api|Farah Juma|
> |jakarta.interceptor:jakarta.interceptor-api|Yeray Borges|
> |jakarta.jms:jakarta.jms-api|Emmanuel Hugonnet|
> |jakarta.management.j2ee:jakarta.management.j2ee-api|Jeff Mesnil|
> |jakarta.resource:jakarta.resource-api|Stefano Maestri|
> |jakarta.security.auth.message:jakarta.security.auth.message-api|Darran Lofthouse / Farah Juma|
> |jakarta.security.jacc:jakarta.security.jacc-api|Darran Lofthouse / Farah Juma|
> |jakarta.servlet:jakarta.servlet-api|Flavia Rainone|
> |jakarta.servlet.jsp:jakarta.servlet.jsp-api|Flavia Rainone|
> |jakarta.transaction:jakarta.transaction-api|Tom Jenkinson|
> |jakarta.websocket:jakarta.websocket-all|Flavia Rainone|
> |jakarta.ws.rs:jakarta.ws.rs-api|Ron Sigal|
> |jakarta.xml.bind:jakarta.xml.bind-api|Jim Ma|
> |jakarta.xml.rpc:jakarta.xml.rpc-api|Jim Ma|
> |jakarta.xml.soap:jakarta.xml.soap-api|Jim Ma|
> |jakarta.xml.ws:jakarta.xml.ws-api|Jim Ma|
>
--
This message was sent by Atlassian Jira
(v7.12.1#712002)
6 years, 9 months
[JBoss JIRA] (WFLY-12300) Convert to Jakarta EE 8 specification APIs
by Scott Marlow (Jira)
[ https://issues.jboss.org/browse/WFLY-12300?page=com.atlassian.jira.plugin... ]
Scott Marlow updated WFLY-12300:
--------------------------------
Description:
This is a top-level task for moving WildFly to specification API artifacts associated with Jakarta EE 8.
The Jakarta EE 8 spec APIs are meant to be fully compatible with their Java EE 8 analogues, so this is not expected to result in runtime behavioral differences.
I don't anticipate code changes specific to this top level task. Instead changes will be associated with other issues linked to this one.
The overall goal is to use API jars that either directly come from the Jakarta EE projects, or that use code closely based on those projects; i.e. that are forks derived from the Jakarta EE code that incorporate jboss.org specific changes and whose maintainers monitor the Jakarta EE projects and bring over needed changes and contribute any relevant jboss.org changes back.
For each JBoss specification API fork that existed in EAP 7.2, a designated owner for that API jar has been determined. The task for each owner consists of:
# Create/update a jboss.org Jakarta fork.
# Track work on that fork via issues in the https://issues.jboss.org/projects/JBEE JIRA project. If there is a high-level issue for that fork, the component owner *should* link it to this issue via a 'relates to' link.
# For the fork, the component owner *must* create a WFLY or WFCORE JIRA to track the change of the WildFly code to use the Jarkarta EE based artifact. That can either be a subtask of this task, or a separate issue linked to this once such that that issue is 'incorporated by' this one. That JIRA should have priority 'Critical' and should have its Fix Version set to 18.0.0.Final or 10.0.0.Final for WFCORE.
Generally, WildFly and WildFly Core do not accept non-Final artifacts into their master branch. For projects that we are forking from the Jakarta EE projects, we are making an exception to this rule:
_Once a Jakarta API project has made a staging release and submitted the specification for formal approval, it is acceptable for the jboss.org fork of that project to produce a CR release based on the code in that staged release and ask that it be incorporated into master._
_In fact, doing this is strongly encouraged as it allows us to further verify the fork._
Once the staged release is approved, the component owner *must* as soon as possible (e.g. the next working day) produce a .Final artifact from the fork and submit a component upgrade PR.
For artifacts that will not involve a fork (e.g. JPA), the component owner should plan to file a PR moving to the Jakarta artifact (e.g. jakarta.persistence:jakarta.persistence-api) as soon as the official version after Jakarta is available in maven central (after Jakarta EE 8 final release).
Following are the relevant APIs, organized by the maven GA of the artifact produced by the Jakarta project, along with the 'owner' of that component:
||API||Owner||
|jakarta.annotation:jakarta.annotation-api|Yeray Borges|
|jakarta.batch:jakarta.batch-api|Cheng Fang|
|jakarta.ejb:jakarta.ejb-api|Cheng Fang/Tomasz Adamski|
|jakarta.el:jakarta.el-api|Scott Marlow|
|jakarta.enterprise:jakarta.enterprise.cdi-spec|Matej Novotny|
|jakarta.enterprise.concurrent:jakarta.enterprise.concurrent-api|Eduardo Martins|
|jakarta.faces:jakarta.faces-api|Farah Juma|
|jakarta.interceptor:jakarta.interceptor-api|Yeray Borges|
|jakarta.jms:jakarta.jms-api|Emmanuel Hugonnet|
|jakarta.json:jakarta.json-api|James Perkins|
|jakarta.json.bind:jakarta.json.bind-api|James Perkins|
|jakarta.management.j2ee:jakarta.management.j2ee-api|Jeff Mesnil|
|jakarta.persistence:jakarta.persistence-api|Scott Marlow|
|jakarta.resource:jakarta.resource-api|Stefano Maestri|
|jakarta.security.auth.message:jakarta.security.auth.message-api|Darran Lofthouse / Farah Juma|
|jakarta.security.jacc:jakarta.security.jacc-api|Darran Lofthouse / Farah Juma|
|jakarta.servlet:jakarta.servlet-api|Flavia Rainone|
|jakarta.servlet.jsp:jakarta.servlet.jsp-api|Flavia Rainone|
|jakarta.servlet.jsp.jstl:jakarta.servlet.jsp.jstl-api|Flavia Rainone|
|jakarta.transaction:jakarta.transaction-api|Tom Jenkinson|
|jakarta.validation:jakarta.validation-api|Brian Stansberry|
|jakarta.websocket:jakarta.websocket-all|Flavia Rainone|
|jakarta.ws.rs:jakarta.ws.rs-api|Ron Sigal|
|jakarta.xml.bind:jakarta.xml.bind-api|Jim Ma|
|jakarta.xml.rpc:jakarta.xml.rpc-api|Jim Ma|
|jakarta.xml.soap:jakarta.xml.soap-api|Jim Ma|
|jakarta.xml.ws:jakarta.xml.ws-api|Jim Ma|
was:
This is a top-level task for moving WildFly to specification API artifacts associated with Jakarta EE 8.
The Jakarta EE 8 spec APIs are meant to be fully compatible with their Java EE 8 analogues, so this is not expected to result in runtime behavioral differences.
I don't anticipate code changes specific to this top level task. Instead changes will be associated with other issues linked to this one.
The overall goal is to use API jars that either directly come from the Jakarta EE projects, or that use code closely based on those projects; i.e. that are forks derived from the Jakarta EE code that incorporate jboss.org specific changes and whose maintainers monitor the Jakarta EE projects and bring over needed changes and contribute any relevant jboss.org changes back.
For each specification API,that w a designated owner for that API jar has been determined. The task for each owner consists of:
# Determining whether there is a need for a jboss.org fork.
# If there is a need for a fork, track work on that fork via issues in the https://issues.jboss.org/projects/JBEE JIRA project. If there is a high-level issue for that fork, the component owner *should* link it to this issue via a 'relates to' link.
# Whether there is a need for a fork or the Jakarta EE project will be directly consumed, the component owner *must* create a WFLY or WFCORE JIRA to track the change of the WildFly code to use the Jarkarta EE based artifact. That can either be a subtask of this task, or a separate issue linked to this once such that that issue is 'incorporated by' this one. That JIRA should have priority 'Critical' and should have its Fix Version set to 18.0.0.Final or 10.0.0.Final for WFCORE.
Generally, WildFly and WildFly Core do not accept non-Final artifacts into their master branch. For projects that we are forking from the Jakarta EE projects, we are making an exception to this rule:
_Once a Jakarta API project has made a staging release and submitted the specification for formal approval, it is acceptable for the jboss.org fork of that project to produce a CR release based on the code in that staged release and ask that it be incorporated into master._
_In fact, doing this is strongly encouraged as it allows us to further verify the fork._
Once the staged release is approved, the component owner *must* as soon as possible (e.g. the next working day) produce a .Final artifact from the fork and submit a component upgrade PR.
For artifacts that will not involve a fork, the component owner should plan to file a PR moving to the Jakarta artifact as soon as the official version is available in maven central.
Following are the relevant APIs, organized by the maven GA of the artifact produced by the Jakarta project, along with the 'owner' of that component:
||API||Owner||
|jakarta.annotation:jakarta.annotation-api|Yeray Borges|
|jakarta.batch:jakarta.batch-api|Cheng Fang|
|jakarta.ejb:jakarta.ejb-api|Cheng Fang/Tomasz Adamski|
|jakarta.el:jakarta.el-api|Scott Marlow|
|jakarta.enterprise:jakarta.enterprise.cdi-spec|Matej Novotny|
|jakarta.enterprise.concurrent:jakarta.enterprise.concurrent-api|Eduardo Martins|
|jakarta.faces:jakarta.faces-api|Farah Juma|
|jakarta.interceptor:jakarta.interceptor-api|Yeray Borges|
|jakarta.jms:jakarta.jms-api|Emmanuel Hugonnet|
|jakarta.json:jakarta.json-api|James Perkins|
|jakarta.json.bind:jakarta.json.bind-api|James Perkins|
|jakarta.management.j2ee:jakarta.management.j2ee-api|Jeff Mesnil|
|jakarta.persistence:jakarta.persistence-api|Scott Marlow|
|jakarta.resource:jakarta.resource-api|Stefano Maestri|
|jakarta.security.auth.message:jakarta.security.auth.message-api|Darran Lofthouse / Farah Juma|
|jakarta.security.jacc:jakarta.security.jacc-api|Darran Lofthouse / Farah Juma|
|jakarta.servlet:jakarta.servlet-api|Flavia Rainone|
|jakarta.servlet.jsp:jakarta.servlet.jsp-api|Flavia Rainone|
|jakarta.servlet.jsp.jstl:jakarta.servlet.jsp.jstl-api|Flavia Rainone|
|jakarta.transaction:jakarta.transaction-api|Tom Jenkinson|
|jakarta.validation:jakarta.validation-api|Brian Stansberry|
|jakarta.websocket:jakarta.websocket-all|Flavia Rainone|
|jakarta.ws.rs:jakarta.ws.rs-api|Ron Sigal|
|jakarta.xml.bind:jakarta.xml.bind-api|Jim Ma|
|jakarta.xml.rpc:jakarta.xml.rpc-api|Jim Ma|
|jakarta.xml.soap:jakarta.xml.soap-api|Jim Ma|
|jakarta.xml.ws:jakarta.xml.ws-api|Jim Ma|
> Convert to Jakarta EE 8 specification APIs
> ------------------------------------------
>
> Key: WFLY-12300
> URL: https://issues.jboss.org/browse/WFLY-12300
> Project: WildFly
> Issue Type: Task
> Components: Server
> Reporter: Brian Stansberry
> Assignee: Scott Marlow
> Priority: Critical
> Fix For: 18.0.0.Final
>
>
> This is a top-level task for moving WildFly to specification API artifacts associated with Jakarta EE 8.
> The Jakarta EE 8 spec APIs are meant to be fully compatible with their Java EE 8 analogues, so this is not expected to result in runtime behavioral differences.
> I don't anticipate code changes specific to this top level task. Instead changes will be associated with other issues linked to this one.
> The overall goal is to use API jars that either directly come from the Jakarta EE projects, or that use code closely based on those projects; i.e. that are forks derived from the Jakarta EE code that incorporate jboss.org specific changes and whose maintainers monitor the Jakarta EE projects and bring over needed changes and contribute any relevant jboss.org changes back.
> For each JBoss specification API fork that existed in EAP 7.2, a designated owner for that API jar has been determined. The task for each owner consists of:
> # Create/update a jboss.org Jakarta fork.
> # Track work on that fork via issues in the https://issues.jboss.org/projects/JBEE JIRA project. If there is a high-level issue for that fork, the component owner *should* link it to this issue via a 'relates to' link.
> # For the fork, the component owner *must* create a WFLY or WFCORE JIRA to track the change of the WildFly code to use the Jarkarta EE based artifact. That can either be a subtask of this task, or a separate issue linked to this once such that that issue is 'incorporated by' this one. That JIRA should have priority 'Critical' and should have its Fix Version set to 18.0.0.Final or 10.0.0.Final for WFCORE.
> Generally, WildFly and WildFly Core do not accept non-Final artifacts into their master branch. For projects that we are forking from the Jakarta EE projects, we are making an exception to this rule:
> _Once a Jakarta API project has made a staging release and submitted the specification for formal approval, it is acceptable for the jboss.org fork of that project to produce a CR release based on the code in that staged release and ask that it be incorporated into master._
> _In fact, doing this is strongly encouraged as it allows us to further verify the fork._
> Once the staged release is approved, the component owner *must* as soon as possible (e.g. the next working day) produce a .Final artifact from the fork and submit a component upgrade PR.
> For artifacts that will not involve a fork (e.g. JPA), the component owner should plan to file a PR moving to the Jakarta artifact (e.g. jakarta.persistence:jakarta.persistence-api) as soon as the official version after Jakarta is available in maven central (after Jakarta EE 8 final release).
> Following are the relevant APIs, organized by the maven GA of the artifact produced by the Jakarta project, along with the 'owner' of that component:
> ||API||Owner||
> |jakarta.annotation:jakarta.annotation-api|Yeray Borges|
> |jakarta.batch:jakarta.batch-api|Cheng Fang|
> |jakarta.ejb:jakarta.ejb-api|Cheng Fang/Tomasz Adamski|
> |jakarta.el:jakarta.el-api|Scott Marlow|
> |jakarta.enterprise:jakarta.enterprise.cdi-spec|Matej Novotny|
> |jakarta.enterprise.concurrent:jakarta.enterprise.concurrent-api|Eduardo Martins|
> |jakarta.faces:jakarta.faces-api|Farah Juma|
> |jakarta.interceptor:jakarta.interceptor-api|Yeray Borges|
> |jakarta.jms:jakarta.jms-api|Emmanuel Hugonnet|
> |jakarta.json:jakarta.json-api|James Perkins|
> |jakarta.json.bind:jakarta.json.bind-api|James Perkins|
> |jakarta.management.j2ee:jakarta.management.j2ee-api|Jeff Mesnil|
> |jakarta.persistence:jakarta.persistence-api|Scott Marlow|
> |jakarta.resource:jakarta.resource-api|Stefano Maestri|
> |jakarta.security.auth.message:jakarta.security.auth.message-api|Darran Lofthouse / Farah Juma|
> |jakarta.security.jacc:jakarta.security.jacc-api|Darran Lofthouse / Farah Juma|
> |jakarta.servlet:jakarta.servlet-api|Flavia Rainone|
> |jakarta.servlet.jsp:jakarta.servlet.jsp-api|Flavia Rainone|
> |jakarta.servlet.jsp.jstl:jakarta.servlet.jsp.jstl-api|Flavia Rainone|
> |jakarta.transaction:jakarta.transaction-api|Tom Jenkinson|
> |jakarta.validation:jakarta.validation-api|Brian Stansberry|
> |jakarta.websocket:jakarta.websocket-all|Flavia Rainone|
> |jakarta.ws.rs:jakarta.ws.rs-api|Ron Sigal|
> |jakarta.xml.bind:jakarta.xml.bind-api|Jim Ma|
> |jakarta.xml.rpc:jakarta.xml.rpc-api|Jim Ma|
> |jakarta.xml.soap:jakarta.xml.soap-api|Jim Ma|
> |jakarta.xml.ws:jakarta.xml.ws-api|Jim Ma|
>
--
This message was sent by Atlassian Jira
(v7.12.1#712002)
6 years, 9 months
[JBoss JIRA] (WFLY-12300) Convert to Jakarta EE 8 specification APIs
by Scott Marlow (Jira)
[ https://issues.jboss.org/browse/WFLY-12300?page=com.atlassian.jira.plugin... ]
Scott Marlow updated WFLY-12300:
--------------------------------
Description:
This is a top-level task for moving WildFly to specification API artifacts associated with Jakarta EE 8.
The Jakarta EE 8 spec APIs are meant to be fully compatible with their Java EE 8 analogues, so this is not expected to result in runtime behavioral differences.
I don't anticipate code changes specific to this top level task. Instead changes will be associated with other issues linked to this one.
The overall goal is to use API jars that either directly come from the Jakarta EE projects, or that use code closely based on those projects; i.e. that are forks derived from the Jakarta EE code that incorporate jboss.org specific changes and whose maintainers monitor the Jakarta EE projects and bring over needed changes and contribute any relevant jboss.org changes back.
For each specification API,that w a designated owner for that API jar has been determined. The task for each owner consists of:
# Determining whether there is a need for a jboss.org fork.
# If there is a need for a fork, track work on that fork via issues in the https://issues.jboss.org/projects/JBEE JIRA project. If there is a high-level issue for that fork, the component owner *should* link it to this issue via a 'relates to' link.
# Whether there is a need for a fork or the Jakarta EE project will be directly consumed, the component owner *must* create a WFLY or WFCORE JIRA to track the change of the WildFly code to use the Jarkarta EE based artifact. That can either be a subtask of this task, or a separate issue linked to this once such that that issue is 'incorporated by' this one. That JIRA should have priority 'Critical' and should have its Fix Version set to 18.0.0.Final or 10.0.0.Final for WFCORE.
Generally, WildFly and WildFly Core do not accept non-Final artifacts into their master branch. For projects that we are forking from the Jakarta EE projects, we are making an exception to this rule:
_Once a Jakarta API project has made a staging release and submitted the specification for formal approval, it is acceptable for the jboss.org fork of that project to produce a CR release based on the code in that staged release and ask that it be incorporated into master._
_In fact, doing this is strongly encouraged as it allows us to further verify the fork._
Once the staged release is approved, the component owner *must* as soon as possible (e.g. the next working day) produce a .Final artifact from the fork and submit a component upgrade PR.
For artifacts that will not involve a fork, the component owner should plan to file a PR moving to the Jakarta artifact as soon as the official version is available in maven central.
Following are the relevant APIs, organized by the maven GA of the artifact produced by the Jakarta project, along with the 'owner' of that component:
||API||Owner||
|jakarta.annotation:jakarta.annotation-api|Yeray Borges|
|jakarta.batch:jakarta.batch-api|Cheng Fang|
|jakarta.ejb:jakarta.ejb-api|Cheng Fang/Tomasz Adamski|
|jakarta.el:jakarta.el-api|Scott Marlow|
|jakarta.enterprise:jakarta.enterprise.cdi-spec|Matej Novotny|
|jakarta.enterprise.concurrent:jakarta.enterprise.concurrent-api|Eduardo Martins|
|jakarta.faces:jakarta.faces-api|Farah Juma|
|jakarta.interceptor:jakarta.interceptor-api|Yeray Borges|
|jakarta.jms:jakarta.jms-api|Emmanuel Hugonnet|
|jakarta.json:jakarta.json-api|James Perkins|
|jakarta.json.bind:jakarta.json.bind-api|James Perkins|
|jakarta.management.j2ee:jakarta.management.j2ee-api|Jeff Mesnil|
|jakarta.persistence:jakarta.persistence-api|Scott Marlow|
|jakarta.resource:jakarta.resource-api|Stefano Maestri|
|jakarta.security.auth.message:jakarta.security.auth.message-api|Darran Lofthouse / Farah Juma|
|jakarta.security.jacc:jakarta.security.jacc-api|Darran Lofthouse / Farah Juma|
|jakarta.servlet:jakarta.servlet-api|Flavia Rainone|
|jakarta.servlet.jsp:jakarta.servlet.jsp-api|Flavia Rainone|
|jakarta.servlet.jsp.jstl:jakarta.servlet.jsp.jstl-api|Flavia Rainone|
|jakarta.transaction:jakarta.transaction-api|Tom Jenkinson|
|jakarta.validation:jakarta.validation-api|Brian Stansberry|
|jakarta.websocket:jakarta.websocket-all|Flavia Rainone|
|jakarta.ws.rs:jakarta.ws.rs-api|Ron Sigal|
|jakarta.xml.bind:jakarta.xml.bind-api|Jim Ma|
|jakarta.xml.rpc:jakarta.xml.rpc-api|Jim Ma|
|jakarta.xml.soap:jakarta.xml.soap-api|Jim Ma|
|jakarta.xml.ws:jakarta.xml.ws-api|Jim Ma|
was:
This is a top-level task for moving WildFly to specification API artifacts associated with Jakarta EE 8.
The Jakarta EE 8 spec APIs are meant to be fully compatible with their Java EE 8 analogues, so this is not expected to result in runtime behavioral differences.
I don't anticipate code changes specific to this top level task. Instead changes will be associated with other issues linked to this one.
The overall goal is to use API jars that either directly come from the Jakarta EE projects, or that use code closely based on those projects; i.e. that are forks derived from the Jakarta EE code that incorporate jboss.org specific changes and whose maintainers monitor the Jakarta EE projects and bring over needed changes and contribute any relevant jboss.org changes back.
For each specification API, a designated owner for that API jar has been determined. The task for each owner consists of:
# Determining whether there is a need for a jboss.org fork.
# If there is a need for a fork, track work on that fork via issues in the https://issues.jboss.org/projects/JBEE JIRA project. If there is a high-level issue for that fork, the component owner *should* link it to this issue via a 'relates to' link.
# Whether there is a need for a fork or the Jakarta EE project will be directly consumed, the component owner *must* create a WFLY or WFCORE JIRA to track the change of the WildFly code to use the Jarkarta EE based artifact. That can either be a subtask of this task, or a separate issue linked to this once such that that issue is 'incorporated by' this one. That JIRA should have priority 'Critical' and should have its Fix Version set to 18.0.0.Final or 10.0.0.Final for WFCORE.
Generally, WildFly and WildFly Core do not accept non-Final artifacts into their master branch. For projects that we are forking from the Jakarta EE projects, we are making an exception to this rule:
_Once a Jakarta API project has made a staging release and submitted the specification for formal approval, it is acceptable for the jboss.org fork of that project to produce a CR release based on the code in that staged release and ask that it be incorporated into master._
_In fact, doing this is strongly encouraged as it allows us to further verify the fork._
Once the staged release is approved, the component owner *must* as soon as possible (e.g. the next working day) produce a .Final artifact from the fork and submit a component upgrade PR.
For artifacts that will not involve a fork, the component owner should plan to file a PR moving to the Jakarta artifact as soon as the official version is available in maven central.
Following are the relevant APIs, organized by the maven GA of the artifact produced by the Jakarta project, along with the 'owner' of that component:
||API||Owner||
|jakarta.annotation:jakarta.annotation-api|Yeray Borges|
|jakarta.batch:jakarta.batch-api|Cheng Fang|
|jakarta.ejb:jakarta.ejb-api|Cheng Fang/Tomasz Adamski|
|jakarta.el:jakarta.el-api|Scott Marlow|
|jakarta.enterprise:jakarta.enterprise.cdi-spec|Matej Novotny|
|jakarta.enterprise.concurrent:jakarta.enterprise.concurrent-api|Eduardo Martins|
|jakarta.faces:jakarta.faces-api|Farah Juma|
|jakarta.interceptor:jakarta.interceptor-api|Yeray Borges|
|jakarta.jms:jakarta.jms-api|Emmanuel Hugonnet|
|jakarta.json:jakarta.json-api|James Perkins|
|jakarta.json.bind:jakarta.json.bind-api|James Perkins|
|jakarta.management.j2ee:jakarta.management.j2ee-api|Jeff Mesnil|
|jakarta.persistence:jakarta.persistence-api|Scott Marlow|
|jakarta.resource:jakarta.resource-api|Stefano Maestri|
|jakarta.security.auth.message:jakarta.security.auth.message-api|Darran Lofthouse / Farah Juma|
|jakarta.security.jacc:jakarta.security.jacc-api|Darran Lofthouse / Farah Juma|
|jakarta.servlet:jakarta.servlet-api|Flavia Rainone|
|jakarta.servlet.jsp:jakarta.servlet.jsp-api|Flavia Rainone|
|jakarta.servlet.jsp.jstl:jakarta.servlet.jsp.jstl-api|Flavia Rainone|
|jakarta.transaction:jakarta.transaction-api|Tom Jenkinson|
|jakarta.validation:jakarta.validation-api|Brian Stansberry|
|jakarta.websocket:jakarta.websocket-all|Flavia Rainone|
|jakarta.ws.rs:jakarta.ws.rs-api|Ron Sigal|
|jakarta.xml.bind:jakarta.xml.bind-api|Jim Ma|
|jakarta.xml.rpc:jakarta.xml.rpc-api|Jim Ma|
|jakarta.xml.soap:jakarta.xml.soap-api|Jim Ma|
|jakarta.xml.ws:jakarta.xml.ws-api|Jim Ma|
> Convert to Jakarta EE 8 specification APIs
> ------------------------------------------
>
> Key: WFLY-12300
> URL: https://issues.jboss.org/browse/WFLY-12300
> Project: WildFly
> Issue Type: Task
> Components: Server
> Reporter: Brian Stansberry
> Assignee: Scott Marlow
> Priority: Critical
> Fix For: 18.0.0.Final
>
>
> This is a top-level task for moving WildFly to specification API artifacts associated with Jakarta EE 8.
> The Jakarta EE 8 spec APIs are meant to be fully compatible with their Java EE 8 analogues, so this is not expected to result in runtime behavioral differences.
> I don't anticipate code changes specific to this top level task. Instead changes will be associated with other issues linked to this one.
> The overall goal is to use API jars that either directly come from the Jakarta EE projects, or that use code closely based on those projects; i.e. that are forks derived from the Jakarta EE code that incorporate jboss.org specific changes and whose maintainers monitor the Jakarta EE projects and bring over needed changes and contribute any relevant jboss.org changes back.
> For each specification API,that w a designated owner for that API jar has been determined. The task for each owner consists of:
> # Determining whether there is a need for a jboss.org fork.
> # If there is a need for a fork, track work on that fork via issues in the https://issues.jboss.org/projects/JBEE JIRA project. If there is a high-level issue for that fork, the component owner *should* link it to this issue via a 'relates to' link.
> # Whether there is a need for a fork or the Jakarta EE project will be directly consumed, the component owner *must* create a WFLY or WFCORE JIRA to track the change of the WildFly code to use the Jarkarta EE based artifact. That can either be a subtask of this task, or a separate issue linked to this once such that that issue is 'incorporated by' this one. That JIRA should have priority 'Critical' and should have its Fix Version set to 18.0.0.Final or 10.0.0.Final for WFCORE.
> Generally, WildFly and WildFly Core do not accept non-Final artifacts into their master branch. For projects that we are forking from the Jakarta EE projects, we are making an exception to this rule:
> _Once a Jakarta API project has made a staging release and submitted the specification for formal approval, it is acceptable for the jboss.org fork of that project to produce a CR release based on the code in that staged release and ask that it be incorporated into master._
> _In fact, doing this is strongly encouraged as it allows us to further verify the fork._
> Once the staged release is approved, the component owner *must* as soon as possible (e.g. the next working day) produce a .Final artifact from the fork and submit a component upgrade PR.
> For artifacts that will not involve a fork, the component owner should plan to file a PR moving to the Jakarta artifact as soon as the official version is available in maven central.
> Following are the relevant APIs, organized by the maven GA of the artifact produced by the Jakarta project, along with the 'owner' of that component:
> ||API||Owner||
> |jakarta.annotation:jakarta.annotation-api|Yeray Borges|
> |jakarta.batch:jakarta.batch-api|Cheng Fang|
> |jakarta.ejb:jakarta.ejb-api|Cheng Fang/Tomasz Adamski|
> |jakarta.el:jakarta.el-api|Scott Marlow|
> |jakarta.enterprise:jakarta.enterprise.cdi-spec|Matej Novotny|
> |jakarta.enterprise.concurrent:jakarta.enterprise.concurrent-api|Eduardo Martins|
> |jakarta.faces:jakarta.faces-api|Farah Juma|
> |jakarta.interceptor:jakarta.interceptor-api|Yeray Borges|
> |jakarta.jms:jakarta.jms-api|Emmanuel Hugonnet|
> |jakarta.json:jakarta.json-api|James Perkins|
> |jakarta.json.bind:jakarta.json.bind-api|James Perkins|
> |jakarta.management.j2ee:jakarta.management.j2ee-api|Jeff Mesnil|
> |jakarta.persistence:jakarta.persistence-api|Scott Marlow|
> |jakarta.resource:jakarta.resource-api|Stefano Maestri|
> |jakarta.security.auth.message:jakarta.security.auth.message-api|Darran Lofthouse / Farah Juma|
> |jakarta.security.jacc:jakarta.security.jacc-api|Darran Lofthouse / Farah Juma|
> |jakarta.servlet:jakarta.servlet-api|Flavia Rainone|
> |jakarta.servlet.jsp:jakarta.servlet.jsp-api|Flavia Rainone|
> |jakarta.servlet.jsp.jstl:jakarta.servlet.jsp.jstl-api|Flavia Rainone|
> |jakarta.transaction:jakarta.transaction-api|Tom Jenkinson|
> |jakarta.validation:jakarta.validation-api|Brian Stansberry|
> |jakarta.websocket:jakarta.websocket-all|Flavia Rainone|
> |jakarta.ws.rs:jakarta.ws.rs-api|Ron Sigal|
> |jakarta.xml.bind:jakarta.xml.bind-api|Jim Ma|
> |jakarta.xml.rpc:jakarta.xml.rpc-api|Jim Ma|
> |jakarta.xml.soap:jakarta.xml.soap-api|Jim Ma|
> |jakarta.xml.ws:jakarta.xml.ws-api|Jim Ma|
>
--
This message was sent by Atlassian Jira
(v7.12.1#712002)
6 years, 9 months
[JBoss JIRA] (JGRP-2335) JDBC_PING: code for determining the coordinator hangs in certain conditions
by Bela Ban (Jira)
[ https://issues.jboss.org/browse/JGRP-2335?page=com.atlassian.jira.plugin.... ]
Bela Ban commented on JGRP-2335:
--------------------------------
OK, yes, let me know!
Cheers,
> JDBC_PING: code for determining the coordinator hangs in certain conditions
> ---------------------------------------------------------------------------
>
> Key: JGRP-2335
> URL: https://issues.jboss.org/browse/JGRP-2335
> Project: JGroups
> Issue Type: Bug
> Reporter: Aieksiei Illarionov
> Assignee: Bela Ban
> Priority: Major
> Fix For: 4.1.3
>
>
> Affected version:
> {code:xml}
> <dependency>
> <groupId>org.jgroups</groupId>
> <artifactId>jgroups</artifactId>
> <version>4.0.0.Final</version>
> </dependency>
> {code}
> ClientGmsImpl#joinInternal hangs because #firstOfAllClients always returns false when all of the following conditions are satisfied:
> - using JDBC_PING for discovery protocol
> - JGROUPSPING table contains data from previous sessions
> - all of the previous sessions were killed (kill -9)
> - AddressGenerator is not customized
> The sorted set
> {code:java}
> SortedSet<Address> clients=new TreeSet<>();
> {code}
> contains the dead servers discovered from JGROUPSPING. When the new server is added to the sorted set, it never becomes the first in the sorted set.
> Suggestions: either
> a) somehow involve MembershipChangePolicy in ordering strategy, or
> b) make the new server (joiner) the first in the sorted set, or
> c) make UUID addresses to sort depending on their time of creation.
> I've used the following config:
> {code:xml}
> <!--
> TCP based stack, with flow control and message bundling. This is usually used when IP
> multicasting cannot be used in a network, e.g. because it is disabled (routers discard multicast).
> Note that TCP.bind_addr and TCPPING.initial_hosts should be set, possibly via system properties, e.g.
> -Djgroups.bind_addr=192.168.5.2 and -Djgroups.tcpping.initial_hosts=192.168.5.2[7800]
> author: Bela Ban
> -->
> <config xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance"
> xmlns="urn:org:jgroups"
> xmlns:fork="fork"
> xsi:schemaLocation="urn:org:jgroups http://www.jgroups.org/schema/jgroups.xsd fork http://www.jgroups.org/schema/fork-stacks.xsd">
> <TCP bind_port="7800"
> port_range="10"
> bind_addr="<placeholder here>"
> recv_buf_size="${tcp.recv_buf_size:130k}"
> send_buf_size="${tcp.send_buf_size:130k}"
> max_bundle_size="64K"
> sock_conn_timeout="300"
> thread_pool.min_threads="0"
> thread_pool.max_threads="20"
> thread_pool.keep_alive_time="30000"/>
> <JDBC_PING
> remove_all_data_on_view_change="true"
> connection_driver="com.microsoft.sqlserver.jdbc.SQLServerDriver"
> connection_url="jdbc:sqlserver://localhost:1433;databaseName=mydatabase"
> connection_username="user"
> connection_password="password"
> />
> <MERGE3 min_interval="10000"
> max_interval="30000"/>
> <FD_SOCK/>
> <FD timeout="3000" max_tries="3" />
> <VERIFY_SUSPECT timeout="1500" />
> <BARRIER />
> <pbcast.NAKACK2 use_mcast_xmit="false"
> discard_delivered_msgs="true"/>
> <UNICAST3
> conn_close_timeout="240000"
> xmit_interval="5000"/>
> <pbcast.STABLE desired_avg_gossip="50000"
> max_bytes="4M"/>
> <pbcast.GMS print_local_addr="true" join_timeout="2000"
> view_bundling="true"
> membership_change_policy="ru.illar.AppMembershipChangePolicy"/>
> <MFC max_credits="2M"
> min_threshold="0.4"/>
> <FRAG2 frag_size="60K" />
> <!--RSVP resend_interval="2000" timeout="10000"/-->
> <pbcast.STATE_TRANSFER/>
> </config>
> {code}
--
This message was sent by Atlassian Jira
(v7.12.1#712002)
6 years, 9 months
[JBoss JIRA] (WFLY-12279) EE Concurrency Capability API
by Eduardo Martins (Jira)
[ https://issues.jboss.org/browse/WFLY-12279?page=com.atlassian.jira.plugin... ]
Eduardo Martins updated WFLY-12279:
-----------------------------------
Description: EE Concurrency resource definitions should have capabilities, which should manage related MSC services. (was: There are several EE Concurrency resources which other subsystems (than EE) interact with, and that should be done using Capability API.)
> EE Concurrency Capability API
> -----------------------------
>
> Key: WFLY-12279
> URL: https://issues.jboss.org/browse/WFLY-12279
> Project: WildFly
> Issue Type: Enhancement
> Components: Concurrency Utilities
> Reporter: Eduardo Martins
> Assignee: Eduardo Martins
> Priority: Major
>
> EE Concurrency resource definitions should have capabilities, which should manage related MSC services.
--
This message was sent by Atlassian Jira
(v7.12.1#712002)
6 years, 9 months