February 2017 - jboss-jira - Jboss List Archives

[JBoss JIRA] (WFLY-4889) JSF application without CDI causes Undertow to crash on deployment

by Farah Juma (JIRA)

[ https://issues.jboss.org/browse/WFLY-4889?page=com.atlassian.jira.plugin.... ] Farah Juma resolved WFLY-4889. ------------------------------ Fix Version/s: 10.0.0.Final Resolution: Out of Date > JSF application without CDI causes Undertow to crash on deployment > ------------------------------------------------------------------ > > Key: WFLY-4889 > URL: https://issues.jboss.org/browse/WFLY-4889 > Project: WildFly > Issue Type: Bug > Components: JSF > Affects Versions: 9.0.0.Final > Reporter: Ken Finnigan > Assignee: Farah Juma > Fix For: 10.0.0.Final > > > My understanding of the JSF spec is that CDI is not a requirement for JSF to function, though there may be some parts of CDI that are required. > If I deploy a very simple JSF app to Undertow without CDI, I get the following stack trace: > {noformat} > Caused by: java.lang.NullPointerException > at java.util.concurrent.ConcurrentHashMap.putVal(ConcurrentHashMap.java:1011) > at java.util.concurrent.ConcurrentHashMap.putAll(ConcurrentHashMap.java:1084) > at io.undertow.servlet.spec.ServletContextImpl.<init>(ServletContextImpl.java:128) > at io.undertow.servlet.core.DeploymentManagerImpl.deploy(DeploymentManagerImpl.java:148) > at org.wildfly.extension.undertow.deployment.UndertowDeploymentService.startContext(UndertowDeploymentService.java:100) > at org.wildfly.extension.undertow.deployment.UndertowDeploymentService$1.run(UndertowDeploymentService.java:82) > ... 6 more > {noformat} > From debugging the value being {{put}} that causes the NPE, it is attempting to add a value of {{null}} for the key {{javax.faces.validator.beanValidator.ValidatorFactory}}. > I believe this is a result of https://github.com/wildfly/wildfly/blob/master/jsf/subsystem/src/main/jav... adding the validation factory as a servlet context attribute whether the retrieval found one or not. -- This message was sent by Atlassian JIRA (v7.2.3#72005)

9 years, 2 months

1
0
0 / 0

[JBoss JIRA] (WFLY-4889) JSF application without CDI causes Undertow to crash on deployment

by Ken Finnigan (JIRA)

[ https://issues.jboss.org/browse/WFLY-4889?page=com.atlassian.jira.plugin.... ] Ken Finnigan commented on WFLY-4889: ------------------------------------ >From looking at the same code in WF 10, it looks like it now checks whether one is found before adding the attachment. So can close as resolved in WF 10 > JSF application without CDI causes Undertow to crash on deployment > ------------------------------------------------------------------ > > Key: WFLY-4889 > URL: https://issues.jboss.org/browse/WFLY-4889 > Project: WildFly > Issue Type: Bug > Components: JSF > Affects Versions: 9.0.0.Final > Reporter: Ken Finnigan > Assignee: Farah Juma > > My understanding of the JSF spec is that CDI is not a requirement for JSF to function, though there may be some parts of CDI that are required. > If I deploy a very simple JSF app to Undertow without CDI, I get the following stack trace: > {noformat} > Caused by: java.lang.NullPointerException > at java.util.concurrent.ConcurrentHashMap.putVal(ConcurrentHashMap.java:1011) > at java.util.concurrent.ConcurrentHashMap.putAll(ConcurrentHashMap.java:1084) > at io.undertow.servlet.spec.ServletContextImpl.<init>(ServletContextImpl.java:128) > at io.undertow.servlet.core.DeploymentManagerImpl.deploy(DeploymentManagerImpl.java:148) > at org.wildfly.extension.undertow.deployment.UndertowDeploymentService.startContext(UndertowDeploymentService.java:100) > at org.wildfly.extension.undertow.deployment.UndertowDeploymentService$1.run(UndertowDeploymentService.java:82) > ... 6 more > {noformat} > From debugging the value being {{put}} that causes the NPE, it is attempting to add a value of {{null}} for the key {{javax.faces.validator.beanValidator.ValidatorFactory}}. > I believe this is a result of https://github.com/wildfly/wildfly/blob/master/jsf/subsystem/src/main/jav... adding the validation factory as a servlet context attribute whether the retrieval found one or not. -- This message was sent by Atlassian JIRA (v7.2.3#72005)

9 years, 2 months

1
0
0 / 0

[JBoss JIRA] (WFLY-4889) JSF application without CDI causes Undertow to crash on deployment

by Tomaz Cerar (JIRA)

[ https://issues.jboss.org/browse/WFLY-4889?page=com.atlassian.jira.plugin.... ] Tomaz Cerar commented on WFLY-4889: ----------------------------------- Is this still the case with WildFly 10? > JSF application without CDI causes Undertow to crash on deployment > ------------------------------------------------------------------ > > Key: WFLY-4889 > URL: https://issues.jboss.org/browse/WFLY-4889 > Project: WildFly > Issue Type: Bug > Components: JSF > Affects Versions: 9.0.0.Final > Reporter: Ken Finnigan > Assignee: Farah Juma > > My understanding of the JSF spec is that CDI is not a requirement for JSF to function, though there may be some parts of CDI that are required. > If I deploy a very simple JSF app to Undertow without CDI, I get the following stack trace: > {noformat} > Caused by: java.lang.NullPointerException > at java.util.concurrent.ConcurrentHashMap.putVal(ConcurrentHashMap.java:1011) > at java.util.concurrent.ConcurrentHashMap.putAll(ConcurrentHashMap.java:1084) > at io.undertow.servlet.spec.ServletContextImpl.<init>(ServletContextImpl.java:128) > at io.undertow.servlet.core.DeploymentManagerImpl.deploy(DeploymentManagerImpl.java:148) > at org.wildfly.extension.undertow.deployment.UndertowDeploymentService.startContext(UndertowDeploymentService.java:100) > at org.wildfly.extension.undertow.deployment.UndertowDeploymentService$1.run(UndertowDeploymentService.java:82) > ... 6 more > {noformat} > From debugging the value being {{put}} that causes the NPE, it is attempting to add a value of {{null}} for the key {{javax.faces.validator.beanValidator.ValidatorFactory}}. > I believe this is a result of https://github.com/wildfly/wildfly/blob/master/jsf/subsystem/src/main/jav... adding the validation factory as a servlet context attribute whether the retrieval found one or not. -- This message was sent by Atlassian JIRA (v7.2.3#72005)

9 years, 2 months

1
0
0 / 0

[JBoss JIRA] (JBEE-171) Java EE 7 API: unable to validate expressions with method invocations

by Tomaz Cerar (JIRA)

[ https://issues.jboss.org/browse/JBEE-171?page=com.atlassian.jira.plugin.s... ] Tomaz Cerar moved WFLY-7796 to JBEE-171: ---------------------------------------- Project: JBoss JavaEE Spec APIs (was: WildFly) Key: JBEE-171 (was: WFLY-7796) Workflow: classic default workflow (was: GIT Pull Request workflow ) Component/s: jboss-jsf-api (was: JSF) Affects Version/s: (was: 10.1.0.Final) > Java EE 7 API: unable to validate expressions with method invocations > --------------------------------------------------------------------- > > Key: JBEE-171 > URL: https://issues.jboss.org/browse/JBEE-171 > Project: JBoss JavaEE Spec APIs > Issue Type: Bug > Components: jboss-jsf-api > Reporter: Markus Pollak > Assignee: Dmitrii Tikhomirov > > Hello, > I’ve found a bug in the javaee-api-7.0.jar: > *Problem:* > javax.faces.validator.ValueExpressionAnalyzer$InterceptingResolver should also override (and delegate) the method "invoke" from ELResolver otherwise the BeanValidator wouldn’t support expressions with method invocations (e.g. #{exampleBean.anyMethod(anyParam).value}. Currently it doesn’t override the method so the default implementation is taken which returns null and leads to problems… > Best Regards, > Markus Pollak -- This message was sent by Atlassian JIRA (v7.2.3#72005)

9 years, 2 months

1
0
0 / 0

[JBoss JIRA] (JBEE-171) Java EE 7 API: unable to validate expressions with method invocations

by Tomaz Cerar (JIRA)

[ https://issues.jboss.org/browse/JBEE-171?page=com.atlassian.jira.plugin.s... ] Tomaz Cerar commented on JBEE-171: ---------------------------------- solutions looks ok. > Java EE 7 API: unable to validate expressions with method invocations > --------------------------------------------------------------------- > > Key: JBEE-171 > URL: https://issues.jboss.org/browse/JBEE-171 > Project: JBoss JavaEE Spec APIs > Issue Type: Bug > Components: jboss-jsf-api > Reporter: Markus Pollak > Assignee: Dmitrii Tikhomirov > > Hello, > I’ve found a bug in the javaee-api-7.0.jar: > *Problem:* > javax.faces.validator.ValueExpressionAnalyzer$InterceptingResolver should also override (and delegate) the method "invoke" from ELResolver otherwise the BeanValidator wouldn’t support expressions with method invocations (e.g. #{exampleBean.anyMethod(anyParam).value}. Currently it doesn’t override the method so the default implementation is taken which returns null and leads to problems… > Best Regards, > Markus Pollak -- This message was sent by Atlassian JIRA (v7.2.3#72005)

9 years, 2 months

1
0
0 / 0

[JBoss JIRA] (WFLY-4889) JSF application without CDI causes Undertow to crash on deployment

by Jeremy Whiting (JIRA)

[ https://issues.jboss.org/browse/WFLY-4889?page=com.atlassian.jira.plugin.... ] Jeremy Whiting updated WFLY-4889: --------------------------------- Comment: was deleted (was: A workaround is to add an empty beans.xml file to the archive.) > JSF application without CDI causes Undertow to crash on deployment > ------------------------------------------------------------------ > > Key: WFLY-4889 > URL: https://issues.jboss.org/browse/WFLY-4889 > Project: WildFly > Issue Type: Bug > Components: JSF > Affects Versions: 9.0.0.Final > Reporter: Ken Finnigan > Assignee: Farah Juma > > My understanding of the JSF spec is that CDI is not a requirement for JSF to function, though there may be some parts of CDI that are required. > If I deploy a very simple JSF app to Undertow without CDI, I get the following stack trace: > {noformat} > Caused by: java.lang.NullPointerException > at java.util.concurrent.ConcurrentHashMap.putVal(ConcurrentHashMap.java:1011) > at java.util.concurrent.ConcurrentHashMap.putAll(ConcurrentHashMap.java:1084) > at io.undertow.servlet.spec.ServletContextImpl.<init>(ServletContextImpl.java:128) > at io.undertow.servlet.core.DeploymentManagerImpl.deploy(DeploymentManagerImpl.java:148) > at org.wildfly.extension.undertow.deployment.UndertowDeploymentService.startContext(UndertowDeploymentService.java:100) > at org.wildfly.extension.undertow.deployment.UndertowDeploymentService$1.run(UndertowDeploymentService.java:82) > ... 6 more > {noformat} > From debugging the value being {{put}} that causes the NPE, it is attempting to add a value of {{null}} for the key {{javax.faces.validator.beanValidator.ValidatorFactory}}. > I believe this is a result of https://github.com/wildfly/wildfly/blob/master/jsf/subsystem/src/main/jav... adding the validation factory as a servlet context attribute whether the retrieval found one or not. -- This message was sent by Atlassian JIRA (v7.2.3#72005)

9 years, 2 months

1
0
0 / 0

[JBoss JIRA] (WFLY-7196) The outcome of xa_commit call on non exiting transaction is silently ignored

by Johnathon Lee (JIRA)

[ https://issues.jboss.org/browse/WFLY-7196?page=com.atlassian.jira.plugin.... ] Johnathon Lee updated WFLY-7196: -------------------------------- > The outcome of xa_commit call on non exiting transaction is silently ignored > ---------------------------------------------------------------------------- > > Key: WFLY-7196 > URL: https://issues.jboss.org/browse/WFLY-7196 > Project: WildFly > Issue Type: Bug > Components: EJB > Affects Versions: 10.1.0.Final > Reporter: Tom Ross > Assignee: Flavia Rainone > > This is from mail thread on transactional mailing list: > {noformat} > There is definitely a bug in EJBR. > These two at least look wrong by inspection: > https://github.com/wildfly/wildfly/blob/master/ejb3/src/main/java/org/jbo... > https://github.com/wildfly/wildfly/blob/master/ejb3/src/main/java/org/jbo... > The way they are implemented means that when the transaction manager calls commit/prepare on an Xid if there is no transaction at the remote side EJBR just ignores the problem whereas it needs to return an XA error so the TM knows about it. > You could simulate this with a test case that gets hold of the EJBR XAResource and invokes: > xar.prepare(dummyXid) and does not get back XAER_NOTA > That explains how the root transaction can prepare/commit without error as we can see here: > 2016-09-12 16:04:02,303 TRACE [com.arjuna.ats.jta] (EJB async - 8) XAResourceRecord.topLevelPrepare for XAResourceRecord < resource:ResourceImpl{transactionKey=0:ffff0af7f6b6:6b296e38:57d14447:63f2e, ejbClientContext=org.jboss.ejb.client.EJBClientContext@18d6826a, nodeName='svc-2-presentation', state=State{transactionID=org.jboss.ejb.client.XidTransactionID@303ce194, suspended=false, participantCnt=0}}, txid:< formatId=131077, gtrid_length=46, bqual_length=36, tx_uid=0:ffff0af7f6b6:6b296e38:57d14447:63f2e, node_name=svc_2_presentation, branch_uid=0:ffff0af7f6b6:6b296e38:57d14447:63f4a, subordinatenodename=null, eis_name=unknown eis name >, heuristic: TwoPhaseOutcome.FINISH_OK com.arjuna.ats.internal.jta.resources.arjunacore.XAResourceRecord@1754f10f >, record id=0:ffff0af7f6b6:6b296e38:57d14447:63f4b > 2016-09-12 16:04:02,364 TRACE [com.arjuna.ats.jta] (EJB async - 8) XAResourceRecord.topLevelCommit for XAResourceRecord < resource:ResourceImpl{transactionKey=0:ffff0af7f6b6:6b296e38:57d14447:63f2e, ejbClientContext=org.jboss.ejb.client.EJBClientContext@18d6826a, nodeName='svc-2-presentation', state=null}, txid:< formatId=131077, gtrid_length=46, bqual_length=36, tx_uid=0:ffff0af7f6b6:6b296e38:57d14447:63f2e, node_name=svc_2_presentation, branch_uid=0:ffff0af7f6b6:6b296e38:57d14447:63f4a, subordinatenodename=null, eis_name=unknown eis name >, heuristic: TwoPhaseOutcome.FINISH_OK com.arjuna.ats.internal.jta.resources.arjunacore.XAResourceRecord@1754f10f >, record id=0:ffff0af7f6b6:6b296e38:57d14447:63f4b > Both those lines I indicated above have debug statements but they should be ERROR and return appropriate XA exceptions. > What it does not explain is why the transaction is initially imported 45 minutes later. I guess it is stuck in some EJB processing queue. > What I think needs curing first is the data integrity issue (i.e. silently ignoring if there is no imported transaction) in the EJB remoting transport. That should be relatively easy as EJBR can just return appropriate errors when it can't find the imported transaction. This part should be tackled urgently. > After that the strange error where the import is processed late should be tackled but I am not familiar enough with the EJB remoting async architecture to suggest how to proceed with that. > {noformat} -- This message was sent by Atlassian JIRA (v7.2.3#72005)

9 years, 2 months

1
0
0 / 0

[JBoss JIRA] (WFLY-4889) JSF application without CDI causes Undertow to crash on deployment

by Jeremy Whiting (JIRA)

[ https://issues.jboss.org/browse/WFLY-4889?page=com.atlassian.jira.plugin.... ] Jeremy Whiting commented on WFLY-4889: -------------------------------------- A workaround is to add an empty beans.xml file to the archive. > JSF application without CDI causes Undertow to crash on deployment > ------------------------------------------------------------------ > > Key: WFLY-4889 > URL: https://issues.jboss.org/browse/WFLY-4889 > Project: WildFly > Issue Type: Bug > Components: JSF > Affects Versions: 9.0.0.Final > Reporter: Ken Finnigan > Assignee: Farah Juma > > My understanding of the JSF spec is that CDI is not a requirement for JSF to function, though there may be some parts of CDI that are required. > If I deploy a very simple JSF app to Undertow without CDI, I get the following stack trace: > {noformat} > Caused by: java.lang.NullPointerException > at java.util.concurrent.ConcurrentHashMap.putVal(ConcurrentHashMap.java:1011) > at java.util.concurrent.ConcurrentHashMap.putAll(ConcurrentHashMap.java:1084) > at io.undertow.servlet.spec.ServletContextImpl.<init>(ServletContextImpl.java:128) > at io.undertow.servlet.core.DeploymentManagerImpl.deploy(DeploymentManagerImpl.java:148) > at org.wildfly.extension.undertow.deployment.UndertowDeploymentService.startContext(UndertowDeploymentService.java:100) > at org.wildfly.extension.undertow.deployment.UndertowDeploymentService$1.run(UndertowDeploymentService.java:82) > ... 6 more > {noformat} > From debugging the value being {{put}} that causes the NPE, it is attempting to add a value of {{null}} for the key {{javax.faces.validator.beanValidator.ValidatorFactory}}. > I believe this is a result of https://github.com/wildfly/wildfly/blob/master/jsf/subsystem/src/main/jav... adding the validation factory as a servlet context attribute whether the retrieval found one or not. -- This message was sent by Atlassian JIRA (v7.2.3#72005)

9 years, 2 months

1
0
0 / 0

[JBoss JIRA] (WFCORE-2278) credential-reference not able to use masked passwords

by Peter Skopek (JIRA)

[ https://issues.jboss.org/browse/WFCORE-2278?page=com.atlassian.jira.plugi... ] Peter Skopek commented on WFCORE-2278: -------------------------------------- There was way to use masked passwords introduced, but decryption on the elytron side has changed. For now, we decided to go with PicketBox compatible and simple enough algorithm. > credential-reference not able to use masked passwords > ----------------------------------------------------- > > Key: WFCORE-2278 > URL: https://issues.jboss.org/browse/WFCORE-2278 > Project: WildFly Core > Issue Type: Bug > Components: Security > Affects Versions: 3.0.0.Alpha24 > Reporter: Peter Skopek > Assignee: Peter Skopek > Priority: Blocker > > credential-reference cannot use PBE encrypted credentials AKA masked passwords (MASK-). -- This message was sent by Atlassian JIRA (v7.2.3#72005)

9 years, 2 months

1
0
0 / 0

[JBoss JIRA] (WFCORE-2278) credential-reference not able to use masked passwords

by Peter Skopek (JIRA)

Peter Skopek created WFCORE-2278: ------------------------------------ Summary: credential-reference not able to use masked passwords Key: WFCORE-2278 URL: https://issues.jboss.org/browse/WFCORE-2278 Project: WildFly Core Issue Type: Bug Components: Security Affects Versions: 3.0.0.Alpha24 Reporter: Peter Skopek Assignee: Peter Skopek Priority: Blocker credential-reference cannot use PBE encrypted credentials AKA masked passwords (MASK-). -- This message was sent by Atlassian JIRA (v7.2.3#72005)

9 years, 2 months

1
0
0 / 0

2026

2025

2024

2023

2022

2021

2020

2019

2018

2017

2016

2015

2014

2013

2012

2011

2010

2009

2008

2007

2006

jboss-jira February 2017