March 2015 - jboss-jira - Jboss List Archives

[JBoss JIRA] (WFLY-4405) NPE in AstValue.setValue()

by Christer Bernérus (JIRA)

[ https://issues.jboss.org/browse/WFLY-4405?page=com.atlassian.jira.plugin.... ] Christer Bernérus updated WFLY-4405: ------------------------------------ Description: When submitting a page made up using a custom tag, or a composite component, WildFly reports NPE in AstValue.setValue(). The code where this happens is in javax.el-3.0.1-b05.jar and looks like this: {code:title=AstValue.java|borderStyle=solid} /* Note by kchung 10/2013 * The spec does not say if the value should be cocerced to the target * type before setting the value to the target. The conversion is kept * here to be backward compatible. */ ctx.setPropertyResolved(false); Class<?> targetType = elResolver.getType(ctx, t.base, property); if (ctx.isPropertyResolved()) { ctx.setPropertyResolved(false); Object targetValue = elResolver.convertToType(ctx, value, targetType); if (ctx.isPropertyResolved()) { value = targetValue; } else { if (value != null || targetType.isPrimitive()) { value = ELSupport.coerceToType(value, targetType); } } } {code} >From my debugging session, I have seen that the code in {{elResolver.getType()}} may return null, which happens to me, but the subsequent code in {{AstValue.setValue()}} happily uses that null valued variable {{targetType}} for calling the method {{isPrimitive()}} which of course causes an NPE. Strangely enough, this behaviour seems intermittent in that restarting WildFly might make the bug go away or come back, but redeployment does not. was: When submitting a page made up using a custom tag, or a composite component, WildFly reports NPE in AstValue.setValue(). The code where this happens is in javax.el-3.0.1-b05.jar and looks like this: {code:title=AstValue.java|borderStyle=solid} /* Note by kchung 10/2013 * The spec does not say if the value should be cocerced to the target * type before setting the value to the target. The conversion is kept * here to be backward compatible. */ ctx.setPropertyResolved(false); Class<?> targetType = elResolver.getType(ctx, t.base, property); if (ctx.isPropertyResolved()) { ctx.setPropertyResolved(false); Object targetValue = elResolver.convertToType(ctx, value, targetType); if (ctx.isPropertyResolved()) { value = targetValue; } else { if (value != null || targetType.isPrimitive()) { value = ELSupport.coerceToType(value, targetType); } } } {code} >From my debugging session, I have seen that the code in {{elResolver.convertToType()}} may return null, which happens to me, but the subsequent code in {{AstValue.setValue()}} happily uses that null valued variable {{targetType}} for calling the method {{isPrimitive()}} which of course causes an NPE. Strangely enough, this behaviour seems intermittent in that restarting WildFly might make the bug go away or come back, but redeployment does not. > NPE in AstValue.setValue() > -------------------------- > > Key: WFLY-4405 > URL: https://issues.jboss.org/browse/WFLY-4405 > Project: WildFly > Issue Type: Bug > Components: CDI / Weld, JSF > Affects Versions: 8.2.0.Final > Environment: MacOS X, RHEL6 > Reporter: Christer Bernérus > Assignee: Stuart Douglas > > When submitting a page made up using a custom tag, or a composite component, WildFly reports NPE in AstValue.setValue(). > The code where this happens is in javax.el-3.0.1-b05.jar and looks like this: > {code:title=AstValue.java|borderStyle=solid} > /* Note by kchung 10/2013 > * The spec does not say if the value should be cocerced to the target > * type before setting the value to the target. The conversion is kept > * here to be backward compatible. > */ > ctx.setPropertyResolved(false); > Class<?> targetType = elResolver.getType(ctx, t.base, property); > if (ctx.isPropertyResolved()) { > ctx.setPropertyResolved(false); > Object targetValue = elResolver.convertToType(ctx, value, targetType); > if (ctx.isPropertyResolved()) { > value = targetValue; > } else { > if (value != null || targetType.isPrimitive()) { > value = ELSupport.coerceToType(value, targetType); > } > } > } > {code} > From my debugging session, I have seen that the code in > {{elResolver.getType()}} may return null, which happens to me, > but the subsequent code in {{AstValue.setValue()}} happily uses that null valued variable {{targetType}} for calling the method {{isPrimitive()}} which of course causes an NPE. > Strangely enough, this behaviour seems intermittent in that restarting WildFly might make the bug go away or come back, but redeployment does not. -- This message was sent by Atlassian JIRA (v6.3.11#6341)

9 years, 4 months

1
0
0 / 0

[JBoss JIRA] (WFLY-4405) NPE in AstValue.setValue()

by Christer Bernérus (JIRA)

Christer Bernérus created WFLY-4405: --------------------------------------- Summary: NPE in AstValue.setValue() Key: WFLY-4405 URL: https://issues.jboss.org/browse/WFLY-4405 Project: WildFly Issue Type: Bug Components: CDI / Weld, JSF Affects Versions: 8.2.0.Final Environment: MacOS X, RHEL6 Reporter: Christer Bernérus Assignee: Stuart Douglas When submitting a page made up using a custom tag, or a composite component, WildFly reports NPE in AstValue.setValue(). The code where this happens is in javax.el-3.0.1-b05.jar and looks like this: {code:title=AstValue.java|borderStyle=solid} /* Note by kchung 10/2013 * The spec does not say if the value should be cocerced to the target * type before setting the value to the target. The conversion is kept * here to be backward compatible. */ ctx.setPropertyResolved(false); Class<?> targetType = elResolver.getType(ctx, t.base, property); if (ctx.isPropertyResolved()) { ctx.setPropertyResolved(false); Object targetValue = elResolver.convertToType(ctx, value, targetType); if (ctx.isPropertyResolved()) { value = targetValue; } else { if (value != null || targetType.isPrimitive()) { value = ELSupport.coerceToType(value, targetType); } } } {code} >From my debugging session, I have seen that the code in {{elResolver.convertToType()}} may return null, which happens to me, but the subsequent code in {{AstValue.setValue()}} happily uses that null valued variable {{targetType}} for calling the method {{isPrimitive()}} which of course causes an NPE. Strangely enough, this behaviour seems intermittent in that restarting WildFly might make the bug go away or come back, but redeployment does not. -- This message was sent by Atlassian JIRA (v6.3.11#6341)

9 years, 4 months

1
0
0 / 0

[JBoss JIRA] (WFCORE-580) Recursive read-resource with include-runtime=true assumes all runtime singleton resources will be present.

by Darran Lofthouse (JIRA)

[ https://issues.jboss.org/browse/WFCORE-580?page=com.atlassian.jira.plugin... ] Darran Lofthouse updated WFCORE-580: ------------------------------------ Workaround Description: I have been able to workaround this by not flagging the resource registrations for the singleton resources as being runtime resources. In my case I have the parent regular resource 'alias' to halt any recursive reads that are not include-runtime=true so this workaround may not suit all situations. Workaround: Workaround Exists > Recursive read-resource with include-runtime=true assumes all runtime singleton resources will be present. > ---------------------------------------------------------------------------------------------------------- > > Key: WFCORE-580 > URL: https://issues.jboss.org/browse/WFCORE-580 > Project: WildFly Core > Issue Type: Bug > Components: Domain Management > Affects Versions: 1.0.0.Alpha19 > Reporter: Darran Lofthouse > Assignee: Brian Stansberry > Labels: affects_elytron > Fix For: 1.0.0.Beta1 > > > Take the following hierarchy: - > keystore=xxx > alias=yyy > certificate-chain=default > certificate-chain=x509 > keystore is a regular resource with storage=configuration. > alias is a regular resource with storage=runtime > certificate-chain=default and certificate-chain=x509 are regular resources with storage=runtime. > So alias represents a single alias from a Java KeyStore, this may or may not have a certificate chain and it may be a default chain or it may be an x509 chain. > The recursive read-resource is fine with regular resources such as alias as it has to rely on the underlying resource implementation to identify the instances that actually exist. > For the singleton resources however the following method is called: - > {code} > org.jboss.as.controller.operations.global.GlobalOperationHandlers.getChildAddresses(OperationContext, PathAddress, ImmutableManagementResourceRegistration, Resource, String) > {code} > Within this method the following check takes place: - > {code} > if (resource != null && resource.hasChildren(childType)) { > Set<String> childNames = resource.getChildrenNames(childType); > if (element.isWildcard()) { > set.addAll(childNames); > } else if (childNames.contains(element.getValue())) { > set.add(element.getValue()); > } > {code} > Up to this point all is fine, the children the resource claims are available are the only ones added. > But further down this happens: - > {code} > if (!element.isWildcard()) { > ImmutableManagementResourceRegistration childReg = registry.getSubModel(PathAddress.pathAddress(element)); > if (childReg != null && childReg.isRuntimeOnly()) { > set.add(element.getValue()); > } > } > {code} > So even though the resource was previously checked and missing children excluded they are now added back. > The end result in this example is that the recursive read resource attempts to read for certificate-chain=default when it should only be reading for certificate-chain=x509 as already reported by the resource implementation. > From a discussion in HipChat yesterday there was general agreement this behaviour seems to be wrong, however support for Proxied resources may be (incorrectly) dependent on this. -- This message was sent by Atlassian JIRA (v6.3.11#6341)

9 years, 4 months

1
0
0 / 0

[JBoss JIRA] (WFCORE-580) Recursive read-resource with include-runtime=true assumes all runtime singleton resources will be present.

by Darran Lofthouse (JIRA)

Darran Lofthouse created WFCORE-580: --------------------------------------- Summary: Recursive read-resource with include-runtime=true assumes all runtime singleton resources will be present. Key: WFCORE-580 URL: https://issues.jboss.org/browse/WFCORE-580 Project: WildFly Core Issue Type: Bug Components: Domain Management Affects Versions: 1.0.0.Alpha19 Reporter: Darran Lofthouse Assignee: Brian Stansberry Fix For: 1.0.0.Beta1 Take the following hierarchy: - keystore=xxx alias=yyy certificate-chain=default certificate-chain=x509 keystore is a regular resource with storage=configuration. alias is a regular resource with storage=runtime certificate-chain=default and certificate-chain=x509 are regular resources with storage=runtime. So alias represents a single alias from a Java KeyStore, this may or may not have a certificate chain and it may be a default chain or it may be an x509 chain. The recursive read-resource is fine with regular resources such as alias as it has to rely on the underlying resource implementation to identify the instances that actually exist. For the singleton resources however the following method is called: - {code} org.jboss.as.controller.operations.global.GlobalOperationHandlers.getChildAddresses(OperationContext, PathAddress, ImmutableManagementResourceRegistration, Resource, String) {code} Within this method the following check takes place: - {code} if (resource != null && resource.hasChildren(childType)) { Set<String> childNames = resource.getChildrenNames(childType); if (element.isWildcard()) { set.addAll(childNames); } else if (childNames.contains(element.getValue())) { set.add(element.getValue()); } {code} Up to this point all is fine, the children the resource claims are available are the only ones added. But further down this happens: - {code} if (!element.isWildcard()) { ImmutableManagementResourceRegistration childReg = registry.getSubModel(PathAddress.pathAddress(element)); if (childReg != null && childReg.isRuntimeOnly()) { set.add(element.getValue()); } } {code} So even though the resource was previously checked and missing children excluded they are now added back. The end result in this example is that the recursive read resource attempts to read for certificate-chain=default when it should only be reading for certificate-chain=x509 as already reported by the resource implementation. >From a discussion in HipChat yesterday there was general agreement this behaviour seems to be wrong, however support for Proxied resources may be (incorrectly) dependent on this. -- This message was sent by Atlassian JIRA (v6.3.11#6341)

9 years, 4 months

1
0
0 / 0

[JBoss JIRA] (WFCORE-580) Recursive read-resource with include-runtime=true assumes all runtime singleton resources will be present.

by Darran Lofthouse (JIRA)

[ https://issues.jboss.org/browse/WFCORE-580?page=com.atlassian.jira.plugin... ] Darran Lofthouse updated WFCORE-580: ------------------------------------ Labels: affects_elytron (was: ) > Recursive read-resource with include-runtime=true assumes all runtime singleton resources will be present. > ---------------------------------------------------------------------------------------------------------- > > Key: WFCORE-580 > URL: https://issues.jboss.org/browse/WFCORE-580 > Project: WildFly Core > Issue Type: Bug > Components: Domain Management > Affects Versions: 1.0.0.Alpha19 > Reporter: Darran Lofthouse > Assignee: Brian Stansberry > Labels: affects_elytron > Fix For: 1.0.0.Beta1 > > > Take the following hierarchy: - > keystore=xxx > alias=yyy > certificate-chain=default > certificate-chain=x509 > keystore is a regular resource with storage=configuration. > alias is a regular resource with storage=runtime > certificate-chain=default and certificate-chain=x509 are regular resources with storage=runtime. > So alias represents a single alias from a Java KeyStore, this may or may not have a certificate chain and it may be a default chain or it may be an x509 chain. > The recursive read-resource is fine with regular resources such as alias as it has to rely on the underlying resource implementation to identify the instances that actually exist. > For the singleton resources however the following method is called: - > {code} > org.jboss.as.controller.operations.global.GlobalOperationHandlers.getChildAddresses(OperationContext, PathAddress, ImmutableManagementResourceRegistration, Resource, String) > {code} > Within this method the following check takes place: - > {code} > if (resource != null && resource.hasChildren(childType)) { > Set<String> childNames = resource.getChildrenNames(childType); > if (element.isWildcard()) { > set.addAll(childNames); > } else if (childNames.contains(element.getValue())) { > set.add(element.getValue()); > } > {code} > Up to this point all is fine, the children the resource claims are available are the only ones added. > But further down this happens: - > {code} > if (!element.isWildcard()) { > ImmutableManagementResourceRegistration childReg = registry.getSubModel(PathAddress.pathAddress(element)); > if (childReg != null && childReg.isRuntimeOnly()) { > set.add(element.getValue()); > } > } > {code} > So even though the resource was previously checked and missing children excluded they are now added back. > The end result in this example is that the recursive read resource attempts to read for certificate-chain=default when it should only be reading for certificate-chain=x509 as already reported by the resource implementation. > From a discussion in HipChat yesterday there was general agreement this behaviour seems to be wrong, however support for Proxied resources may be (incorrectly) dependent on this. -- This message was sent by Atlassian JIRA (v6.3.11#6341)

9 years, 4 months

1
0
0 / 0

[JBoss JIRA] (WFCORE-579) ProxyMetadataSource does not return JDK8 'default' methods fro minterfaces

by RH Bugzilla Integration (JIRA)

[ https://issues.jboss.org/browse/WFCORE-579?page=com.atlassian.jira.plugin... ] RH Bugzilla Integration updated WFCORE-579: ------------------------------------------- Bugzilla Update: Perform Bugzilla References: https://bugzilla.redhat.com/show_bug.cgi?id=1196686 > ProxyMetadataSource does not return JDK8 'default' methods fro minterfaces > -------------------------------------------------------------------------- > > Key: WFCORE-579 > URL: https://issues.jboss.org/browse/WFCORE-579 > Project: WildFly Core > Issue Type: Bug > Components: Server > Affects Versions: 1.0.0.Alpha19 > Reporter: Bartosz Baranowski > Assignee: Bartosz Baranowski > Fix For: 1.0.0.Beta1 > > -- This message was sent by Atlassian JIRA (v6.3.11#6341)

9 years, 4 months

1
0
0 / 0

[JBoss JIRA] (WFCORE-579) ProxyMetadataSource does not return JDK8 'default' methods fro minterfaces

by Bartosz Baranowski (JIRA)

Bartosz Baranowski created WFCORE-579: ----------------------------------------- Summary: ProxyMetadataSource does not return JDK8 'default' methods fro minterfaces Key: WFCORE-579 URL: https://issues.jboss.org/browse/WFCORE-579 Project: WildFly Core Issue Type: Bug Components: Server Affects Versions: 1.0.0.Alpha19 Reporter: Bartosz Baranowski Assignee: Bartosz Baranowski Fix For: 1.0.0.Beta1 -- This message was sent by Atlassian JIRA (v6.3.11#6341)

9 years, 4 months

1
0
0 / 0

[JBoss JIRA] (WFLY-4404) View does not inherit 'default' methods from interfaces( JDK8 )

by RH Bugzilla Integration (JIRA)

[ https://issues.jboss.org/browse/WFLY-4404?page=com.atlassian.jira.plugin.... ] RH Bugzilla Integration updated WFLY-4404: ------------------------------------------ Bugzilla Update: Perform Bugzilla References: https://bugzilla.redhat.com/show_bug.cgi?id=1196686 > View does not inherit 'default' methods from interfaces( JDK8 ) > --------------------------------------------------------------- > > Key: WFLY-4404 > URL: https://issues.jboss.org/browse/WFLY-4404 > Project: WildFly > Issue Type: Bug > Components: Server > Affects Versions: 9.0.0.Alpha1 > Reporter: Bartosz Baranowski > Assignee: Bartosz Baranowski > Fix For: 9.0.0.Beta1 > > > View and View service do not inherit JDK8 'default' methods from interfaces. -- This message was sent by Atlassian JIRA (v6.3.11#6341)

9 years, 4 months

1
0
0 / 0

[JBoss JIRA] (WFLY-4404) View does not inherit 'default' methods from interfaces( JDK8 )

by Bartosz Baranowski (JIRA)

Bartosz Baranowski created WFLY-4404: ---------------------------------------- Summary: View does not inherit 'default' methods from interfaces( JDK8 ) Key: WFLY-4404 URL: https://issues.jboss.org/browse/WFLY-4404 Project: WildFly Issue Type: Bug Components: Server Affects Versions: 9.0.0.Alpha1 Reporter: Bartosz Baranowski Assignee: Jason Greene Fix For: 9.0.0.Beta1 View and View service do not inherit JDK8 'default' methods from interfaces. -- This message was sent by Atlassian JIRA (v6.3.11#6341)

9 years, 4 months

1
0
0 / 0

[JBoss JIRA] (WFLY-4404) View does not inherit 'default' methods from interfaces( JDK8 )

by Bartosz Baranowski (JIRA)

[ https://issues.jboss.org/browse/WFLY-4404?page=com.atlassian.jira.plugin.... ] Bartosz Baranowski reassigned WFLY-4404: ---------------------------------------- Assignee: Bartosz Baranowski (was: Jason Greene) > View does not inherit 'default' methods from interfaces( JDK8 ) > --------------------------------------------------------------- > > Key: WFLY-4404 > URL: https://issues.jboss.org/browse/WFLY-4404 > Project: WildFly > Issue Type: Bug > Components: Server > Affects Versions: 9.0.0.Alpha1 > Reporter: Bartosz Baranowski > Assignee: Bartosz Baranowski > Fix For: 9.0.0.Beta1 > > > View and View service do not inherit JDK8 'default' methods from interfaces. -- This message was sent by Atlassian JIRA (v6.3.11#6341)

9 years, 4 months

1
0
0 / 0

2024

2023

2022

2021

2020

2019

2018

2017

2016

2015

2014

2013

2012

2011

2010

2009

2008

2007

2006

jboss-jira March 2015