[JBoss JIRA] (WFLY-12617) org.jboss.jbossfaces.WAR_BUNDLES_JSF_IMPL flag ignored when WARs are embedded in EAR
by Angel Olle Blazquez (Jira)
Angel Olle Blazquez created WFLY-12617:
------------------------------------------
Summary: org.jboss.jbossfaces.WAR_BUNDLES_JSF_IMPL flag ignored when WARs are embedded in EAR
Key: WFLY-12617
URL: https://issues.jboss.org/browse/WFLY-12617
Project: WildFly
Issue Type: Bug
Components: JSF
Affects Versions: 15.0.0.Final, 16.0.0.Final, 17.0.0.Final, 18.0.0.Beta1
Reporter: Angel Olle Blazquez
Assignee: Farah Juma
Due to changes indroduced to fix bug WFLY-10796 it is no longer possible to configure wars embedded in ear to bundle jsf implementation.
Changes made in file JSFDependencyProcessor.java in commit 40f72548985a9f5ca31317b01a4a0ce09ee759aa
From:
{code}
final DeploymentUnit tl = deploymentUnit.getParent() == null ? deploymentUnit : deploymentUnit.getParent();
String jsfVersion = JsfVersionMarker.getVersion(tl);
{code}
To:
{code}
String jsfVersion = JsfVersionMarker.getVersion(deploymentUnit);
{code}
modified the way jsf version is aquired. Before the change it was always taken from top level deployment. After it is taken directly from scanned deployment unit without searching in parent. Unfortunately there was no matching change in a way context params from web.xml are processed in JSFVersionProcessor:
{code}
final DeploymentUnit topLevelDeployment = deploymentUnit.getParent() == null ? deploymentUnit : deploymentUnit.getParent();
final WarMetaData metaData = deploymentUnit.getAttachment(WarMetaData.ATTACHMENT_KEY);
List<ParamValueMetaData> contextParams = new ArrayList<ParamValueMetaData>();
if ((metaData.getWebMetaData() != null) && (metaData.getWebMetaData().getContextParams() != null)) {
contextParams.addAll(metaData.getWebMetaData().getContextParams());
}
for (final ParamValueMetaData param : contextParams) {
if ((param.getParamName().equals(WAR_BUNDLES_JSF_IMPL_PARAM) &&
(param.getParamValue() != null) &&
(param.getParamValue().toLowerCase(Locale.ENGLISH).equals("true")))) {
JsfVersionMarker.setVersion(topLevelDeployment, JsfVersionMarker.WAR_BUNDLES_JSF_IMPL);
break; // WAR_BUNDLES_JSF_IMPL always wins
}
if (param.getParamName().equals(JSF_CONFIG_NAME_PARAM)) {
JsfVersionMarker.setVersion(topLevelDeployment, param.getParamValue());
break;
}
}
{code}
So the information about org.jboss.jbossfaces.WAR_BUNDLES_JSF_IMPL flag is only set in top level deployment unit.
This causes Mojarra-2.0 to be returned as jsf version during checks in JSFDependencyProcessor for embedded wars and leads to initialization of default mojarra implementation before bundled implementation is processed. As both implementations are loaded class conflicts occur and it is not possible to properly initialize jsf. In case of myfaces this leads to below error:
{code}
2019-09-16 10:46:23,405 ERROR [org.jboss.msc.service.fail] (ServerService Thread Pool -- 86) MSC000001: Failed to start service jboss.deployment.subunit."xxx.ear"."yyy.war".undertow-deployment: org.jboss.msc.service.StartException in service jboss.deployment.subunit."xxx.ear"."yyy.war".undertow-deployment: java.lang.RuntimeException: java.lang.IllegalStateException: Could not find backup for factory javax.faces.application.ApplicationFactory.
at org.wildfly.extension.undertow.deployment.UndertowDeploymentService$1.run(UndertowDeploymentService.java:81)
at java.util.concurrent.Executors$RunnableAdapter.call(Executors.java:511)
at java.util.concurrent.FutureTask.run(FutureTask.java:266)
at org.jboss.threads.ContextClassLoaderSavingRunnable.run(ContextClassLoaderSavingRunnable.java:35)
at org.jboss.threads.EnhancedQueueExecutor.safeRun(EnhancedQueueExecutor.java:1982)
at org.jboss.threads.EnhancedQueueExecutor$ThreadBody.doRunTask(EnhancedQueueExecutor.java:1486)
at org.jboss.threads.EnhancedQueueExecutor$ThreadBody.run(EnhancedQueueExecutor.java:1377)
at java.lang.Thread.run(Thread.java:748)
at org.jboss.threads.JBossThread.run(JBossThread.java:485)
Caused by: java.lang.RuntimeException: java.lang.IllegalStateException: Could not find backup for factory javax.faces.application.ApplicationFactory.
at io.undertow.servlet.core.DeploymentManagerImpl.deploy(DeploymentManagerImpl.java:252)
at org.wildfly.extension.undertow.deployment.UndertowDeploymentService.startContext(UndertowDeploymentService.java:96)
at org.wildfly.extension.undertow.deployment.UndertowDeploymentService$1.run(UndertowDeploymentService.java:78)
... 8 more
Caused by: java.lang.IllegalStateException: Could not find backup for factory javax.faces.application.ApplicationFactory.
at javax.faces.FactoryFinderInstance.notNullFactory(FactoryFinderInstance.java:524)
at javax.faces.FactoryFinderInstance.getFactory(FactoryFinderInstance.java:207)
at javax.faces.FactoryFinder.getFactory(FactoryFinder.java:279)
at org.apache.myfaces.context.servlet.FacesContextImplBase.getApplication(FacesContextImplBase.java:159)
at org.apache.myfaces.context.servlet.FacesContextImplBase.getELContext(FacesContextImplBase.java:210)
at javax.faces.component.UIViewRoot.setLocale(UIViewRoot.java:1602)
at org.apache.myfaces.webapp.AbstractFacesInitializer._createFacesContext(AbstractFacesInitializer.java:477)
at org.apache.myfaces.webapp.AbstractFacesInitializer.initStartupFacesContext(AbstractFacesInitializer.java:449)
at org.apache.myfaces.webapp.StartupServletContextListener.contextInitialized(StartupServletContextListener.java:113)
at io.undertow.servlet.core.ApplicationListeners.contextInitialized(ApplicationListeners.java:187)
at io.undertow.servlet.core.DeploymentManagerImpl$1.call(DeploymentManagerImpl.java:216)
at io.undertow.servlet.core.DeploymentManagerImpl$1.call(DeploymentManagerImpl.java:185)
at io.undertow.servlet.core.ServletRequestContextThreadSetupAction$1.call(ServletRequestContextThreadSetupAction.java:42)
at io.undertow.servlet.core.ContextClassLoaderSetupAction$1.call(ContextClassLoaderSetupAction.java:43)
at org.wildfly.extension.undertow.security.SecurityContextThreadSetupAction.lambda$create$0(SecurityContextThreadSetupAction.java:105)
at org.wildfly.extension.undertow.deployment.UndertowDeploymentInfoService$UndertowThreadSetupAction.lambda$create$0(UndertowDeploymentInfoService.java:1502)
at org.wildfly.extension.undertow.deployment.UndertowDeploymentInfoService$UndertowThreadSetupAction.lambda$create$0(UndertowDeploymentInfoService.java:1502)
at org.wildfly.extension.undertow.deployment.UndertowDeploymentInfoService$UndertowThreadSetupAction.lambda$create$0(UndertowDeploymentInfoService.java:1502)
at org.wildfly.extension.undertow.deployment.UndertowDeploymentInfoService$UndertowThreadSetupAction.lambda$create$0(UndertowDeploymentInfoService.java:1502)
at io.undertow.servlet.core.DeploymentManagerImpl.deploy(DeploymentManagerImpl.java:250)
... 10 more
{code}
--
This message was sent by Atlassian Jira
(v7.13.8#713008)
6 years
[JBoss JIRA] (DROOLS-4574) Scenario test: UX to add an expression-based value.
by Elizabeth Clayton (Jira)
[ https://issues.jboss.org/browse/DROOLS-4574?page=com.atlassian.jira.plugi... ]
Elizabeth Clayton commented on DROOLS-4574:
-------------------------------------------
[~danielezonca] Just something in the right-panel UI to help the user to understand that they can A) select the parent, and that when they do it will B) set the field as an expression.
- And I know it's out of scope, but for a future consideration - in DMN we're repurposing the DO selector tree widget and adding a checkbox to the parent DO's. See: https://issues.jboss.org/browse/DROOLS-4481. I believe [~karreiro] will be implementing it.
!Screen Shot 2019-10-01 at 8.13.41 AM.png|thumbnail!
> Scenario test: UX to add an expression-based value.
> ----------------------------------------------------
>
> Key: DROOLS-4574
> URL: https://issues.jboss.org/browse/DROOLS-4574
> Project: Drools
> Issue Type: Story
> Components: Scenario Simulation and Testing
> Reporter: Elizabeth Clayton
> Assignee: Elizabeth Clayton
> Priority: Major
> Labels: UX, UXTeam
> Attachments: Screen Shot 2019-10-01 at 8.13.41 AM.png
>
>
> As a technical/advanced user (Cameron), I want to be able to input expression-based values in scenario given/expect row cells, so that I can define inputs for complex objects and logic.
> Note: Syntax highlighting and etc., are out of scope. Refer to: https://issues.jboss.org/browse/DROOLS-3514
--
This message was sent by Atlassian Jira
(v7.13.8#713008)
6 years
[JBoss JIRA] (DROOLS-4585) Focus doesn't moves after the selected cell
by Jozef Marko (Jira)
[ https://issues.jboss.org/browse/DROOLS-4585?page=com.atlassian.jira.plugi... ]
Jozef Marko commented on DROOLS-4585:
-------------------------------------
Yes, but as we use the same grid framework for both, I think would be worth to fix both by one fix. What do you think [~karreiro]?
> Focus doesn't moves after the selected cell
> -------------------------------------------
>
> Key: DROOLS-4585
> URL: https://issues.jboss.org/browse/DROOLS-4585
> Project: Drools
> Issue Type: Bug
> Components: Scenario Simulation and Testing
> Affects Versions: 7.28.0.Final
> Reporter: Anna Dupliak
> Assignee: Yeser Amer
> Priority: Major
> Labels: CustomerFocus
>
> {color:red}*Failure*{color}
> If you navigate cell that is obscured by the right panel in header then it dosen't automatically scrolls to it as it done for grid body.
> *Expected*
> Viewed part of grid follows the selected cell
--
This message was sent by Atlassian Jira
(v7.13.8#713008)
6 years
[JBoss JIRA] (WFWIP-206) scale down isn't successful when there are in-doubt transaction on pod
by Martin Simka (Jira)
[ https://issues.jboss.org/browse/WFWIP-206?page=com.atlassian.jira.plugin.... ]
Martin Simka edited comment on WFWIP-206 at 10/1/19 8:05 AM:
-------------------------------------------------------------
update:
* failure in {{testTxStatelessServerSecondCommitThrowRmFail}} seems to be caused by old EAP image missing some fixes, I'll retest it with fresh image from EAP7-1216
* {{testTxStatelessClientSecondCommitThrowRmFail}} fails intermittently, I created WFWIP-218
* {{testTxStatelessServerSecondPrepareJvmHalt}} pending retest
* {{testTxStatelessClientSecondPrepareJvmHalt}} pending retest
was (Author: simkam):
update:
* failure in {{testTxStatelessServerSecondCommitThrowRmFail}} in seems to be caused by old EAP image missing some fixes
* {{testTxStatelessClientSecondCommitThrowRmFail}} fails intermittently, I created WFWIP-218
* {{testTxStatelessServerSecondPrepareJvmHalt}} pending retest
* {{testTxStatelessClientSecondPrepareJvmHalt}} pending retest
> scale down isn't successful when there are in-doubt transaction on pod
> ----------------------------------------------------------------------
>
> Key: WFWIP-206
> URL: https://issues.jboss.org/browse/WFWIP-206
> Project: WildFly WIP
> Issue Type: Bug
> Components: OpenShift
> Environment: operator, built from [1984d98154f11a7473be065e4ae7f54b1812c9b0|https://github.com/wildfly/wildf...] :
> {noformat}
> docker-registry.engineering.redhat.com/jbossqe-eap/wildfly-operator:latest
> {noformat}
> EAP image:
> {noformat}
> docker-registry.engineering.redhat.com/ochaloup/wildfly18-snapshot:190909...
> {noformat}
> Reporter: Martin Simka
> Assignee: Ondrej Chaloupka
> Priority: Blocker
> Labels: operator
>
> While testing tx recovery in OpenShift I see that scale down of pod that has transaction in-doubt on it isn't successful
> Scenario:
> *ejb client* (app tx-client, pod tx-client-0):
> * EJB business method
> ** lookup remote EJB
> ** enlist XA resource 1 to transaction
> ** enlist XA resource 2 to transaction
> ** call remote EJB
> *ejb server* (app tx-server, pod tx-server-0):
> * EJB business method
> ** enlist XA resource 1 to transaction
> ** enlist XA resource 2 to transaction
> ejb server XA resource 2 fails with {{XAException(XAException.XAER_RMFAIL)}}
> Then the test calls scale down (size from 1 to 0) on tx-server pod. But scale down never completes.
> Log from operator:
> {noformat}
> {"level":"info","ts":1568905676.6303623,"logger":"controller_wildflyserver","msg":"Transaction recovery scaledown processing","Request.Namespace":"msimka-namespace","Request.Name":"tx-server","Pod Name":"tx-server-0","IP Address":"172.17.0.10"}
> {"level":"info","ts":1568905676.7313502,"logger":"controller_wildflyserver","msg":"Enabling recovery listener for processing scaledown at tx-server-0","Request.Namespace":"msimka-namespace","Request.Name":"tx-server"}
> {"level":"info","ts":1568905679.4325309,"logger":"controller_wildflyserver","msg":"Query to find the transaction recovery port to force scan at pod tx-server-0","Request.Namespace":"msimka-namespace","Request.Name":"tx-server"}
> {"level":"info","ts":1568905686.7914035,"logger":"controller_wildflyserver","msg":"Executing recovery scan at tx-server-0","Request.Namespace":"msimka-namespace","Request.Name":"tx-server","Pod IP":"172.17.0.10","Recovery port":4712}
> {"level":"info","ts":1568905702.0583296,"logger":"controller_wildflyserver","msg":"In-doubt transactions in object store","Request.Namespace":"msimka-namespace","Request.Name":"tx-server","Pod Name":"tx-server-0","Message":"Recovery scan to be invoked as the transaction log storage is not empty for pod scaling down pod tx-server-0, transaction list: map[0:ffffac11000a:991c183:5d8399a1:13:map[age-in-seconds:23 id:0:ffffac11000a:991c183:5d8399a1:13 jmx-name:<nil> participants:map[java:/MockXAResource:map[eis-product-name:MockXAResource Test eis-product-version:0.1.Mock jmx-name:<nil> jndi-name:java:/MockXAResource status:PREPARED type:/StateManager/AbstractRecord/XAResourceRecord]] type:StateManager/BasicAction/TwoPhaseCoordinator/AtomicAction/SubordinateAtomicAction/JCA]]"}
> {"level":"info","ts":1568905711.1034026,"logger":"controller_wildflyserver","msg":"Reconciling WildFlyServer","Request.Namespace":"msimka-namespace","Request.Name":"tx-server"}
> {"level":"info","ts":1568905711.103548,"logger":"controller_wildflyserver","msg":"Transaction recovery scaledown processing","Request.Namespace":"msimka-namespace","Request.Name":"tx-server","Pod Name":"tx-server-0","IP Address":"172.17.0.10"}
> {"level":"info","ts":1568905711.109706,"logger":"controller_wildflyserver","msg":"Executing recovery scan at tx-server-0","Request.Namespace":"msimka-namespace","Request.Name":"tx-server","Pod IP":"172.17.0.10","Recovery port":4712}
> {"level":"error","ts":1568905711.2608829,"logger":"controller_wildflyserver","msg":"Failures during scaling down recovery processing","Request.Namespace":"msimka-namespace","Request.Name":"tx-server","Desired replica size":0,"Number of pods to be removed":1,"error":"Found 1 errors:\n [[Failed to run transaction recovery scan for scaling down pod tx-server-0. Please, verify the pod log file. Error: Error to get response for command SCAN sending to 172.17.0.10:4712, error: EOF]],","stacktrace":"github.com/go-logr/zapr.(*zapLogger).Error\n\t/go/pkg/mod/github.com/go-l..."}
> {"level":"info","ts":1568905711.2609518,"logger":"controller_wildflyserver","msg":"Scaling down statefulset by verification if pods are clean by recovery","StatefulSet.Namespace":"msimka-namespace","StatefulSet.Name":"tx-server"}
> {"level":"info","ts":1568905711.2609615,"logger":"controller_wildflyserver","msg":"Statefulset was not fully scaled to the desired replica size 0 while StatefulSet is to be at size 1. Some pods were not cleaned by recovery. Verify status of the WildflyServer tx-server","StatefulSet.Namespace":"msimka-namespace","StatefulSet.Name":"tx-server"}
> {"level":"info","ts":1568905711.2795022,"logger":"controller_wildflyserver","msg":"Updating StatefulSet to be up to date with the WildFlyServer Spec","StatefulSet.Namespace":"msimka-namespace","StatefulSet.Name":"tx-server"}
> {"level":"info","ts":1568905711.2795491,"logger":"controller_wildflyserver","msg":"Reconciling WildFlyServer","Request.Namespace":"msimka-namespace","Request.Name":"tx-server"}
> {"level":"info","ts":1568905711.2796504,"logger":"controller_wildflyserver","msg":"Transaction recovery scaledown processing","Request.Namespace":"msimka-namespace","Request.Name":"tx-server","Pod Name":"tx-server-0","IP Address":"172.17.0.10"}
> {"level":"info","ts":1568905711.2937052,"logger":"controller_wildflyserver","msg":"Executing recovery scan at tx-server-0","Request.Namespace":"msimka-namespace","Request.Name":"tx-server","Pod IP":"172.17.0.10","Recovery port":4712}
> {"level":"error","ts":1568905711.294249,"logger":"controller_wildflyserver","msg":"Failures during scaling down recovery processing","Request.Namespace":"msimka-namespace","Request.Name":"tx-server","Desired replica size":0,"Number of pods to be removed":1,"error":"Found 1 errors:\n [[Failed to run transaction recovery scan for scaling down pod tx-server-0. Please, verify the pod log file. Error: Cannot process TCP connection to 172.17.0.10:4712, error: dial tcp 172.17.0.10:4712: connect: connection refused]],","stacktrace":"github.com/go-logr/zapr.(*zapLogger).Error\n\t/go/pkg/mod/github.com/go-l..."}
> {"level":"info","ts":1568905711.294342,"logger":"controller_wildflyserver","msg":"Scaling down statefulset by verification if pods are clean by recovery","StatefulSet.Namespace":"msimka-namespace","StatefulSet.Name":"tx-server"}
> {"level":"info","ts":1568905711.294417,"logger":"controller_wildflyserver","msg":"Statefulset was not fully scaled to the desired replica size 0 while StatefulSet is to be at size 1. Some pods were not cleaned by recovery. Verify status of the WildflyServer tx-server","StatefulSet.Namespace":"msimka-namespace","StatefulSet.Name":"tx-server"}
> {"level":"error","ts":1568905711.311673,"logger":"controller_wildflyserver","msg":"Failed to Update StatefulSet.","StatefulSet.Namespace":"msimka-namespace","StatefulSet.Name":"tx-server","error":"Operation cannot be fulfilled on statefulsets.apps \"tx-server\": the object has been modified; please apply your changes to the latest version and try again","stacktrace":"github.com/go-logr/zapr.(*zapLogger).Error\n\t/go/pkg/mod/github.com/go-l..."}
> {"level":"error","ts":1568905711.311745,"logger":"kubebuilder.controller","msg":"Reconciler error","controller":"wildflyserver-controller","request":"msimka-namespace/tx-server","error":"Operation cannot be fulfilled on statefulsets.apps \"tx-server\": the object has been modified; please apply your changes to the latest version and try again","stacktrace":"github.com/go-logr/zapr.(*zapLogger).Error\n\t/go/pkg/mod/github.com/go-l..."}
> {"level":"info","ts":1568905712.3137681,"logger":"controller_wildflyserver","msg":"Reconciling WildFlyServer","Request.Namespace":"msimka-namespace","Request.Name":"tx-server"}
> {"level":"info","ts":1568905712.3139439,"logger":"controller_wildflyserver","msg":"Transaction recovery scaledown processing","Request.Namespace":"msimka-namespace","Request.Name":"tx-server","Pod Name":"tx-server-0","IP Address":"172.17.0.10"}
> {"level":"info","ts":1568905712.3253288,"logger":"controller_wildflyserver","msg":"Executing recovery scan at tx-server-0","Request.Namespace":"msimka-namespace","Request.Name":"tx-server","Pod IP":"172.17.0.10","Recovery port":4712}
> {"level":"error","ts":1568905712.3255754,"logger":"controller_wildflyserver","msg":"Failures during scaling down recovery processing","Request.Namespace":"msimka-namespace","Request.Name":"tx-server","Desired replica size":0,"Number of pods to be removed":1,"error":"Found 1 errors:\n [[Failed to run transaction recovery scan for scaling down pod tx-server-0. Please, verify the pod log file. Error: Cannot process TCP connection to 172.17.0.10:4712, error: dial tcp 172.17.0.10:4712: connect: connection refused]],","stacktrace":"github.com/go-logr/zapr.(*zapLogger).Error\n\t/go/pkg/mod/github.com/go-l..."}
> {"level":"info","ts":1568905712.3256311,"logger":"controller_wildflyserver","msg":"Scaling down statefulset by verification if pods are clean by recovery","StatefulSet.Namespace":"msimka-namespace","StatefulSet.Name":"tx-server"}
> {"level":"info","ts":1568905712.3256419,"logger":"controller_wildflyserver","msg":"Statefulset was not fully scaled to the desired replica size 0 while StatefulSet is to be at size 1. Some pods were not cleaned by recovery. Verify status of the WildflyServer tx-server","StatefulSet.Namespace":"msimka-namespace","StatefulSet.Name":"tx-server"}
> {noformat}
--
This message was sent by Atlassian Jira
(v7.13.8#713008)
6 years
[JBoss JIRA] (WFWIP-219) Operator is missing node/pod affinity setting
by Martin Choma (Jira)
Martin Choma created WFWIP-219:
----------------------------------
Summary: Operator is missing node/pod affinity setting
Key: WFWIP-219
URL: https://issues.jboss.org/browse/WFWIP-219
Project: WildFly WIP
Issue Type: Bug
Components: OpenShift
Reporter: Martin Choma
Assignee: Jeff Mesnil
As a user I am able to configure pod/node affinity
{code:yaml}
affinity:
nodeAffinity:
preferredDuringSchedulingIgnoredDuringExecution:
requiredDuringSchedulingIgnoredDuringExecution:
podAffinity:
preferredDuringSchedulingIgnoredDuringExecution:
requiredDuringSchedulingIgnoredDuringExecution:
podAntiAffinity:
preferredDuringSchedulingIgnoredDuringExecution:
requiredDuringSchedulingIgnoredDuringExecution:
nodeName:
nodeSelector:
schedulerName
tolerations"
{code}
[1] https://docs.openshift.com/container-platform/3.11/rest_api/apis-apps/v1b...
--
This message was sent by Atlassian Jira
(v7.13.8#713008)
6 years