[JBoss JIRA] (WFCORE-4596) Write lock is acquired reading patching resource using include-runtime
by Yeray Borges (Jira)
Yeray Borges created WFCORE-4596:
------------------------------------
Summary: Write lock is acquired reading patching resource using include-runtime
Key: WFCORE-4596
URL: https://issues.jboss.org/browse/WFCORE-4596
Project: WildFly Core
Issue Type: Bug
Components: Patching
Reporter: Yeray Borges
Assignee: Yeray Borges
This is initially created as a bug but it needs first some investigation to discover if it is really necessary to acquire the write lock when the patching resource is read. If it is unnecessary, we should remove this need.
The following operation is acquiring the write lock:
{noformat}
/host=slave/core-service=patching:read-resource(include-runtime=true)
{noformat}
It potentially will block if there is any other operation which has already acquired the lock. One consequence found due to this issue was HAL could block and hang if an HC is starting and the user clicks on 'Patching' menu entry. It was fixed in HAL, where HS being restarted are no longer shown in the Patching menu.
The main problem seems to be in PatchStreamResourceOperationStepHandler, which is the parent handler used for the handlers that manage patching operations. This parent handler is always acquiring the write lock.
--
This message was sent by Atlassian Jira
(v7.12.1#712002)
6 years, 9 months
[JBoss JIRA] (SWSQE-919) Update Install-Maistra to Maistra 1.0
by Guilherme Baufaker Rêgo (Jira)
Guilherme Baufaker Rêgo created SWSQE-919:
---------------------------------------------
Summary: Update Install-Maistra to Maistra 1.0
Key: SWSQE-919
URL: https://issues.jboss.org/browse/SWSQE-919
Project: Kiali QE
Issue Type: Bug
Reporter: Guilherme Baufaker Rêgo
Assignee: Guilherme Baufaker Rêgo
Maistra 1.0 is adding more changes to the operators and CR that needs to be persisted on existing pipeline
--
This message was sent by Atlassian Jira
(v7.12.1#712002)
6 years, 9 months
[JBoss JIRA] (WFLY-5966) Validate requirement for modules previously exported by javax.ejb.api
by Yeray Borges (Jira)
[ https://issues.jboss.org/browse/WFLY-5966?page=com.atlassian.jira.plugin.... ]
Yeray Borges updated WFLY-5966:
-------------------------------
Description:
The WFLY-5922 fix removed the exporting of a number of modules from javax.ejb.api. That introduced some problems with modules that depended on those exported packages no longer having visibility to needed classes, so to prevent problems I blindly added a commit to the module.xml for each module that depended upon javax.ejb.api to add a dependency set like this:
{code}
<!-- TODO validate the need for these and remove if not needed.
Prior to WFLY-5922 they were exported by javax.ejb.api. -->
<module name="javax.api"/>
<module name="javax.transaction.api"/>
<module name="javax.xml.rpc.api"/>
<module name="javax.rmi.api"/>
<module name="org.omg.api"/>
{code}
If a module already had a dep on one of those, it's not in the block.
This task is to check each of these modules and replace that block with normal dependency declarations for any that are truly needed.
Affected modules:
-feature-pack/src/main/resources/modules/system/layers/base/javax/management/j2ee/api/main/module.xml-
-feature-pack/src/main/resources/modules/system/layers/base/org/jboss/as/ejb3/main/module.xml-
-feature-pack/src/main/resources/modules/system/layers/base/org/jboss/as/jsr77/main/module.xml-
-feature-pack/src/main/resources/modules/system/layers/base/org/jboss/as/webservices/main/module.xml-
-feature-pack/src/main/resources/modules/system/layers/base/org/jboss/as/weld/main/module.xml-
-feature-pack/src/main/resources/modules/system/layers/base/org/jboss/as/xts/main/module.xml-
-feature-pack/src/main/resources/modules/system/layers/base/org/jboss/ejb-client/main/module.xml-
-feature-pack/src/main/resources/modules/system/layers/base/org/jboss/ejb3/main/module.xml-
-feature-pack/src/main/resources/modules/system/layers/base/org/jboss/iiop-client/main/module.xml-
-feature-pack/src/main/resources/modules/system/layers/base/org/jboss/metadata/appclient/main/module.xml-
-feature-pack/src/main/resources/modules/system/layers/base/org/jboss/metadata/ejb/main/module.xml-
-feature-pack/src/main/resources/modules/system/layers/base/org/jboss/narayana/compensations/main/module.xml-
-feature-pack/src/main/resources/modules/system/layers/base/org/jboss/narayana/rts/main/module.xml-
-feature-pack/src/main/resources/modules/system/layers/base/org/jboss/narayana/txframework/main/module.xml-
-feature-pack/src/main/resources/modules/system/layers/base/org/jboss/weld/core/main/module.xml-
-feature-pack/src/main/resources/modules/system/layers/base/org/jboss/ws/common/main/module.xml-
-feature-pack/src/main/resources/modules/system/layers/base/org/jboss/xts/main/module.xml-
-feature-pack/src/main/resources/modules/system/layers/base/org/wildfly/extension/rts/main/module.xml-
-feature-pack/src/main/resources/modules/system/layers/base/org/jboss/as/jpa/main/module.xml-
-feature-pack/src/main/resources/modules/system/layers/base/org/jboss/as/jpa/spi/main/module.xml-
feature-pack/src/main/resources/modules/system/layers/base/javaee/api/main/module.xml
The following modules were indirectly affected via their dependency on javaee.api, which in turn exports javax.ejb.api:
feature-pack/src/main/resources/modules/system/layers/base/org/jberet/jberet-core/main/module.xml
jsf/multi-jsf-installer/src/main/resources/mojarra-impl-module.xml
jsf/multi-jsf-installer/src/main/resources/myfaces-impl-module.xml
feature-pack/src/main/resources/modules/system/layers/base/com/sun/jsf-impl/main/module.xml
jsf/subsystem/src/test/resources/modules/com/sun/jsf-impl/main/module.xml
jsf/subsystem/src/test/resources/modules/com/sun/jsf-impl/myfaces/module.xml
jsf/subsystem/src/test/resources/modules2/com/sun/jsf-impl/myfaces2/module.xml
was:
The WFLY-5922 fix removed the exporting of a number of modules from javax.ejb.api. That introduced some problems with modules that depended on those exported packages no longer having visibility to needed classes, so to prevent problems I blindly added a commit to the module.xml for each module that depended upon javax.ejb.api to add a dependency set like this:
{code}
<!-- TODO validate the need for these and remove if not needed.
Prior to WFLY-5922 they were exported by javax.ejb.api. -->
<module name="javax.api"/>
<module name="javax.transaction.api"/>
<module name="javax.xml.rpc.api"/>
<module name="javax.rmi.api"/>
<module name="org.omg.api"/>
{code}
If a module already had a dep on one of those, it's not in the block.
This task is to check each of these modules and replace that block with normal dependency declarations for any that are truly needed.
Affected modules:
-feature-pack/src/main/resources/modules/system/layers/base/javax/management/j2ee/api/main/module.xml-
-feature-pack/src/main/resources/modules/system/layers/base/org/jboss/as/ejb3/main/module.xml-
-feature-pack/src/main/resources/modules/system/layers/base/org/jboss/as/jsr77/main/module.xml-
-feature-pack/src/main/resources/modules/system/layers/base/org/jboss/as/webservices/main/module.xml-
-feature-pack/src/main/resources/modules/system/layers/base/org/jboss/as/weld/main/module.xml-
-feature-pack/src/main/resources/modules/system/layers/base/org/jboss/as/xts/main/module.xml-
-feature-pack/src/main/resources/modules/system/layers/base/org/jboss/ejb-client/main/module.xml-
-feature-pack/src/main/resources/modules/system/layers/base/org/jboss/ejb3/main/module.xml-
-feature-pack/src/main/resources/modules/system/layers/base/org/jboss/iiop-client/main/module.xml-
-feature-pack/src/main/resources/modules/system/layers/base/org/jboss/metadata/appclient/main/module.xml-
-feature-pack/src/main/resources/modules/system/layers/base/org/jboss/metadata/ejb/main/module.xml-
-feature-pack/src/main/resources/modules/system/layers/base/org/jboss/narayana/compensations/main/module.xml-
-feature-pack/src/main/resources/modules/system/layers/base/org/jboss/narayana/rts/main/module.xml-
-feature-pack/src/main/resources/modules/system/layers/base/org/jboss/narayana/txframework/main/module.xml-
-feature-pack/src/main/resources/modules/system/layers/base/org/jboss/weld/core/main/module.xml-
feature-pack/src/main/resources/modules/system/layers/base/org/jboss/ws/common/main/module.xml
-feature-pack/src/main/resources/modules/system/layers/base/org/jboss/xts/main/module.xml-
-feature-pack/src/main/resources/modules/system/layers/base/org/wildfly/extension/rts/main/module.xml-
-feature-pack/src/main/resources/modules/system/layers/base/org/jboss/as/jpa/main/module.xml-
-feature-pack/src/main/resources/modules/system/layers/base/org/jboss/as/jpa/spi/main/module.xml-
feature-pack/src/main/resources/modules/system/layers/base/javaee/api/main/module.xml
The following modules were indirectly affected via their dependency on javaee.api, which in turn exports javax.ejb.api:
feature-pack/src/main/resources/modules/system/layers/base/org/jberet/jberet-core/main/module.xml
jsf/multi-jsf-installer/src/main/resources/mojarra-impl-module.xml
jsf/multi-jsf-installer/src/main/resources/myfaces-impl-module.xml
feature-pack/src/main/resources/modules/system/layers/base/com/sun/jsf-impl/main/module.xml
jsf/subsystem/src/test/resources/modules/com/sun/jsf-impl/main/module.xml
jsf/subsystem/src/test/resources/modules/com/sun/jsf-impl/myfaces/module.xml
jsf/subsystem/src/test/resources/modules2/com/sun/jsf-impl/myfaces2/module.xml
> Validate requirement for modules previously exported by javax.ejb.api
> ---------------------------------------------------------------------
>
> Key: WFLY-5966
> URL: https://issues.jboss.org/browse/WFLY-5966
> Project: WildFly
> Issue Type: Task
> Components: Server
> Reporter: Brian Stansberry
> Assignee: Yeray Borges
> Priority: Major
>
> The WFLY-5922 fix removed the exporting of a number of modules from javax.ejb.api. That introduced some problems with modules that depended on those exported packages no longer having visibility to needed classes, so to prevent problems I blindly added a commit to the module.xml for each module that depended upon javax.ejb.api to add a dependency set like this:
> {code}
> <!-- TODO validate the need for these and remove if not needed.
> Prior to WFLY-5922 they were exported by javax.ejb.api. -->
> <module name="javax.api"/>
> <module name="javax.transaction.api"/>
> <module name="javax.xml.rpc.api"/>
> <module name="javax.rmi.api"/>
> <module name="org.omg.api"/>
> {code}
> If a module already had a dep on one of those, it's not in the block.
> This task is to check each of these modules and replace that block with normal dependency declarations for any that are truly needed.
> Affected modules:
> -feature-pack/src/main/resources/modules/system/layers/base/javax/management/j2ee/api/main/module.xml-
> -feature-pack/src/main/resources/modules/system/layers/base/org/jboss/as/ejb3/main/module.xml-
> -feature-pack/src/main/resources/modules/system/layers/base/org/jboss/as/jsr77/main/module.xml-
> -feature-pack/src/main/resources/modules/system/layers/base/org/jboss/as/webservices/main/module.xml-
> -feature-pack/src/main/resources/modules/system/layers/base/org/jboss/as/weld/main/module.xml-
> -feature-pack/src/main/resources/modules/system/layers/base/org/jboss/as/xts/main/module.xml-
> -feature-pack/src/main/resources/modules/system/layers/base/org/jboss/ejb-client/main/module.xml-
> -feature-pack/src/main/resources/modules/system/layers/base/org/jboss/ejb3/main/module.xml-
> -feature-pack/src/main/resources/modules/system/layers/base/org/jboss/iiop-client/main/module.xml-
> -feature-pack/src/main/resources/modules/system/layers/base/org/jboss/metadata/appclient/main/module.xml-
> -feature-pack/src/main/resources/modules/system/layers/base/org/jboss/metadata/ejb/main/module.xml-
> -feature-pack/src/main/resources/modules/system/layers/base/org/jboss/narayana/compensations/main/module.xml-
> -feature-pack/src/main/resources/modules/system/layers/base/org/jboss/narayana/rts/main/module.xml-
> -feature-pack/src/main/resources/modules/system/layers/base/org/jboss/narayana/txframework/main/module.xml-
> -feature-pack/src/main/resources/modules/system/layers/base/org/jboss/weld/core/main/module.xml-
> -feature-pack/src/main/resources/modules/system/layers/base/org/jboss/ws/common/main/module.xml-
> -feature-pack/src/main/resources/modules/system/layers/base/org/jboss/xts/main/module.xml-
> -feature-pack/src/main/resources/modules/system/layers/base/org/wildfly/extension/rts/main/module.xml-
> -feature-pack/src/main/resources/modules/system/layers/base/org/jboss/as/jpa/main/module.xml-
> -feature-pack/src/main/resources/modules/system/layers/base/org/jboss/as/jpa/spi/main/module.xml-
> feature-pack/src/main/resources/modules/system/layers/base/javaee/api/main/module.xml
> The following modules were indirectly affected via their dependency on javaee.api, which in turn exports javax.ejb.api:
> feature-pack/src/main/resources/modules/system/layers/base/org/jberet/jberet-core/main/module.xml
> jsf/multi-jsf-installer/src/main/resources/mojarra-impl-module.xml
> jsf/multi-jsf-installer/src/main/resources/myfaces-impl-module.xml
> feature-pack/src/main/resources/modules/system/layers/base/com/sun/jsf-impl/main/module.xml
> jsf/subsystem/src/test/resources/modules/com/sun/jsf-impl/main/module.xml
> jsf/subsystem/src/test/resources/modules/com/sun/jsf-impl/myfaces/module.xml
> jsf/subsystem/src/test/resources/modules2/com/sun/jsf-impl/myfaces2/module.xml
--
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 Cheng Fang (Jira)
[ https://issues.jboss.org/browse/WFLY-12300?page=com.atlassian.jira.plugin... ]
Cheng Fang edited comment on WFLY-12300 at 8/8/19 2:42 AM:
-----------------------------------------------------------
What's the rules for generating javadocs in these forked api projects? For current jboss batch api fork project, its pom inherits from jboss-parent so the javadocs rules are specified in the parent and influenced by some configurable properties. So the javadoc page footer will have:
Copyright © 2019 JBoss by Red Hat. All rights reserved.
Now it seems Jakarta api projects are required to have a link (license terms) pointing to EFSL.html. For example,
© Copyright IBM Corp. 2014, 2019.
Use is subject to license terms.
So shall we use the upstream javadoc settings, and override the jboss-parent ones? I think we didn't modify the api substantially enough to warrant our own copyright declaration, and using the original Jakarta one is more suitable.
was (Author: cfang):
What's the rules for generating javadocs in these forked api projects? For current jboss batch api fork project, its pom inherits from jboss-parent so the javadocs rules are specified in the parent and influenced by some configurable properties. So the javadoc page footer will have:
Copyright © 2019 JBoss by Red Hat. All rights reserved.
Now it seems Jakarta api projects are required to have a link (license terms) pointing to EFSL.html. For example,
© Copyright IBM Corp. 2014, 2019.
Use is subject to license terms.
So shall we use the upstream javadoc settings, and override the jboss-parent ones? I think we didn't substantially modify the api to warrant our own copyright declaration, and using the original one is more suitable.
> 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 Cheng Fang (Jira)
[ https://issues.jboss.org/browse/WFLY-12300?page=com.atlassian.jira.plugin... ]
Cheng Fang commented on WFLY-12300:
-----------------------------------
What's the rules for generating javadocs in these forked api projects? For current jboss batch api fork project, its pom inherits from jboss-parent so the javadocs rules are specified in the parent and influenced by some configurable properties. So the javadoc page footer will have:
Copyright © 2019 JBoss by Red Hat. All rights reserved.
Now it seems Jakarta api projects are required to have a link (license terms) pointing to EFSL.html. For example,
© Copyright IBM Corp. 2014, 2019.
Use is subject to license terms.
So shall we use the upstream javadoc settings, and override the jboss-parent ones? I think we didn't substantially modify the api to warrant our own copyright declaration, and using the original one is more suitable.
> 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] (DROOLS-4399) KIE Server kie-server-7.24.0.Final-webc fails with ClassNotFoundException
by Simon Dallaway (Jira)
[ https://issues.jboss.org/browse/DROOLS-4399?page=com.atlassian.jira.plugi... ]
Simon Dallaway commented on DROOLS-4399:
----------------------------------------
Hi Maciej,
This is a somewhat uninformed comment but here goes:
I was looking at the problem in the Java Debugger and noticed 2 things
1. The log entry was being made for a thread named Periodic Recovery
2. The context being used to lookup comp/env/xads only had an entry for UserDatabase
UserDatabase is defined in the <GlobalNamingResources> section of the server.xml file. When I move the XA datasource from the context.xml file to the server.xml file and put a ResourceLink entry into the context.xml file the Periodic Recover thread finds it but now fails because the URL associated is empty.
Still investigating but I'm on the train home so I won't get much more done until tomorrow.
> KIE Server kie-server-7.24.0.Final-webc fails with ClassNotFoundException
> -------------------------------------------------------------------------
>
> Key: DROOLS-4399
> URL: https://issues.jboss.org/browse/DROOLS-4399
> Project: Drools
> Issue Type: Bug
> Components: kie server
> Affects Versions: 7.24.0.Final
> Environment: Windows 8.1 x64
> Tomcat 9.0.16
> Reporter: Simon Dallaway
> Assignee: Maciej Swiderski
> Priority: Major
> Attachments: catalina.2019-08-05.log, catalina.2019-08-06.log, catalina.2019-08-08.log, catalina.2019-08-08.log, context.xml, libDir.txt, server.xml, setenv.bat, tomcat-users.xml, xa-recovery-properties.xml
>
>
> Attempting to deploy KIE Server on Tomcat 9 fails with a ClassNotFoundException org.jboss.narayana.tomcat.jta.NarayanaJtaServletContextListener when trying to setup application listener
--
This message was sent by Atlassian Jira
(v7.12.1#712002)
6 years, 9 months