[JBoss JIRA] (WFLY-3215) JSF 1.2 on Wildfly 8 Final - weld-core-jsf is still referencing JSF 2.2 API
by Farah Juma (JIRA)
[ https://issues.jboss.org/browse/WFLY-3215?page=com.atlassian.jira.plugin.... ]
Farah Juma commented on WFLY-3215:
----------------------------------
[~swd847] Do you have any thoughts on what should be done to allow JSF 1.2 to work properly with Weld again on WildFly? The problem here seems to be that the org.jboss.weld.jsf.ConversationAwareViewHandler#getActionURL method was modified so that it now references the javax.faces.context.FacesContext#getAttributes method. This results in a NoSuchMethodError when using JSF 1.2 on WildFly since the getAttributes() method doesn't exist in the JSF 1.2 version of FacesContext.
> JSF 1.2 on Wildfly 8 Final - weld-core-jsf is still referencing JSF 2.2 API
> ---------------------------------------------------------------------------
>
> Key: WFLY-3215
> URL: https://issues.jboss.org/browse/WFLY-3215
> Project: WildFly
> Issue Type: Bug
> Security Level: Public(Everyone can see)
> Components: CDI / Weld, JSF
> Affects Versions: 8.0.0.Final
> Reporter: Stanley Hillner
> Assignee: Farah Juma
>
> I added JSF 1.2 support by follwing [this tutorial|https://community.jboss.org/wiki/StepsToAddAnyNewJSFImplementati...] and the sample project provided by Stan Silvert works fine. But when I deploy our own app I always get the following error message:
> {noformat}
> ERROR [request] UT005023: Exception handling request to /backoffice/login.faces: java.lang.NoSuchMethodError: javax.faces.context.FacesContext.getAttributes()Ljava/util/Map;
> [exec] at org.jboss.weld.jsf.ConversationAwareViewHandler.getActionURL(ConversationAwareViewHandler.java:103)
> [exec] at javax.faces.application.ViewHandlerWrapper.getActionURL(ViewHandlerWrapper.java:147)
> [exec] at com.sun.facelets.FaceletViewHandler.getActionURL(FaceletViewHandler.java:807)
> [exec] at org.apache.myfaces.shared_tomahawk.renderkit.html.HtmlRenderer.getActionUrl(HtmlRenderer.java:77)
> [exec] at org.apache.myfaces.custom.form.HtmlFormRenderer.getActionUrl(HtmlFormRenderer.java:45)
> [exec] at org.apache.myfaces.shared_tomahawk.renderkit.html.HtmlFormRendererBase.encodeBegin(HtmlFormRendererBase.java:102)
> [exec] at org.apache.myfaces.custom.form.HtmlFormRenderer.encodeBegin(HtmlFormRenderer.java:134)
> [exec] at javax.faces.component.UIComponentBase.encodeBegin(UIComponentBase.java:816)
> [exec] at javax.faces.component.UIComponent.encodeAll(UIComponent.java:928)
> [exec] at javax.faces.component.UIComponent.encodeAll(UIComponent.java:933)
> [exec] at com.sun.facelets.FaceletViewHandler.renderView(FaceletViewHandler.java:594)
> [exec] at com.sun.faces.lifecycle.RenderResponsePhase.execute(RenderResponsePhase.java:110)
> [exec] at com.sun.faces.lifecycle.Phase.doPhase(Phase.java:100)
> [exec] at com.sun.faces.lifecycle.LifecycleImpl.render(LifecycleImpl.java:139)
> [exec] at javax.faces.webapp.FacesServlet.service(FacesServlet.java:266)
> ...
> {noformat}
> This message indicates that the jsf-injection module still references a newer JSF API but not the JSF-1.2 API. I also had a look at the implementation of this module and I saw that the class ConversationAwareViewHandler which is included in the new jsf-injection module cannot work with JSF 1.2 since it calls methods from JSF 2.x.
> I also posted this issue [here|http://stackoverflow.com/questions/22758645/jsf-1-2-on-wildfly-8-fin...] and need a solution.
--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators
For more information on JIRA, see: http://www.atlassian.com/software/jira
12 years, 3 months
[JBoss JIRA] (WFLY-3215) JSF 1.2 on Wildfly 8 Final - weld-core-jsf is still referencing JSF 2.2 API
by Farah Juma (JIRA)
[ https://issues.jboss.org/browse/WFLY-3215?page=com.atlassian.jira.plugin.... ]
Farah Juma commented on WFLY-3215:
----------------------------------
Just to clarify a bit, although the <exclude-subsystems> tag does work with sub-deployments, it likely also needs to be specified for the top-level deployment here. When the <exclude-subsystems> tag is specified for a top-level deployment, it will be inherited by sub-deployments.
> JSF 1.2 on Wildfly 8 Final - weld-core-jsf is still referencing JSF 2.2 API
> ---------------------------------------------------------------------------
>
> Key: WFLY-3215
> URL: https://issues.jboss.org/browse/WFLY-3215
> Project: WildFly
> Issue Type: Bug
> Security Level: Public(Everyone can see)
> Components: CDI / Weld, JSF
> Affects Versions: 8.0.0.Final
> Reporter: Stanley Hillner
> Assignee: Farah Juma
>
> I added JSF 1.2 support by follwing [this tutorial|https://community.jboss.org/wiki/StepsToAddAnyNewJSFImplementati...] and the sample project provided by Stan Silvert works fine. But when I deploy our own app I always get the following error message:
> {noformat}
> ERROR [request] UT005023: Exception handling request to /backoffice/login.faces: java.lang.NoSuchMethodError: javax.faces.context.FacesContext.getAttributes()Ljava/util/Map;
> [exec] at org.jboss.weld.jsf.ConversationAwareViewHandler.getActionURL(ConversationAwareViewHandler.java:103)
> [exec] at javax.faces.application.ViewHandlerWrapper.getActionURL(ViewHandlerWrapper.java:147)
> [exec] at com.sun.facelets.FaceletViewHandler.getActionURL(FaceletViewHandler.java:807)
> [exec] at org.apache.myfaces.shared_tomahawk.renderkit.html.HtmlRenderer.getActionUrl(HtmlRenderer.java:77)
> [exec] at org.apache.myfaces.custom.form.HtmlFormRenderer.getActionUrl(HtmlFormRenderer.java:45)
> [exec] at org.apache.myfaces.shared_tomahawk.renderkit.html.HtmlFormRendererBase.encodeBegin(HtmlFormRendererBase.java:102)
> [exec] at org.apache.myfaces.custom.form.HtmlFormRenderer.encodeBegin(HtmlFormRenderer.java:134)
> [exec] at javax.faces.component.UIComponentBase.encodeBegin(UIComponentBase.java:816)
> [exec] at javax.faces.component.UIComponent.encodeAll(UIComponent.java:928)
> [exec] at javax.faces.component.UIComponent.encodeAll(UIComponent.java:933)
> [exec] at com.sun.facelets.FaceletViewHandler.renderView(FaceletViewHandler.java:594)
> [exec] at com.sun.faces.lifecycle.RenderResponsePhase.execute(RenderResponsePhase.java:110)
> [exec] at com.sun.faces.lifecycle.Phase.doPhase(Phase.java:100)
> [exec] at com.sun.faces.lifecycle.LifecycleImpl.render(LifecycleImpl.java:139)
> [exec] at javax.faces.webapp.FacesServlet.service(FacesServlet.java:266)
> ...
> {noformat}
> This message indicates that the jsf-injection module still references a newer JSF API but not the JSF-1.2 API. I also had a look at the implementation of this module and I saw that the class ConversationAwareViewHandler which is included in the new jsf-injection module cannot work with JSF 1.2 since it calls methods from JSF 2.x.
> I also posted this issue [here|http://stackoverflow.com/questions/22758645/jsf-1-2-on-wildfly-8-fin...] and need a solution.
--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators
For more information on JIRA, see: http://www.atlassian.com/software/jira
12 years, 3 months
[JBoss JIRA] (WFLY-3173) Default number of DIST owners is too conservative
by Paul Ferraro (JIRA)
[ https://issues.jboss.org/browse/WFLY-3173?page=com.atlassian.jira.plugin.... ]
Paul Ferraro commented on WFLY-3173:
------------------------------------
Great! It's just a configuration change then.
> Default number of DIST owners is too conservative
> -------------------------------------------------
>
> Key: WFLY-3173
> URL: https://issues.jboss.org/browse/WFLY-3173
> Project: WildFly
> Issue Type: Enhancement
> Security Level: Public(Everyone can see)
> Components: Clustering
> Affects Versions: 8.0.0.Final
> Reporter: Paul Ferraro
> Assignee: Radoslav Husar
> Fix For: 8.0.1.Final
>
>
> WildFly uses DIST by default using 4 owners, which is too conservative. I think we should lower this default value to 2, which is Infinispan's default value. We'll get a nice performance bump too.
> Don't forget to create transformers to handle the default value change for old model versions.
--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators
For more information on JIRA, see: http://www.atlassian.com/software/jira
12 years, 3 months
[JBoss JIRA] (WFLY-3215) JSF 1.2 on Wildfly 8 Final - weld-core-jsf is still referencing JSF 2.2 API
by Stanley Hillner (JIRA)
[ https://issues.jboss.org/browse/WFLY-3215?page=com.atlassian.jira.plugin.... ]
Stanley Hillner commented on WFLY-3215:
---------------------------------------
OK, I didn't know that the exclusions don't work for subdeployments. This way I will need to restructure my deployments. I will try this, as well as your hint regarding the slots on monday. Thank so far!
I will also try to patch the ConversationAwareViewHandler with the older implementation for our setup.
Would it be reasonable to patch the implementation so that it checks the JSF API version and tries to perform the new implementation but falls back to the legacy one in case of older JSF versions? I think this is the desired behavior since this module gets replaced by the multi-JSF installer.
Thanks a lot!
> JSF 1.2 on Wildfly 8 Final - weld-core-jsf is still referencing JSF 2.2 API
> ---------------------------------------------------------------------------
>
> Key: WFLY-3215
> URL: https://issues.jboss.org/browse/WFLY-3215
> Project: WildFly
> Issue Type: Bug
> Security Level: Public(Everyone can see)
> Components: JSF
> Affects Versions: 8.0.0.Final
> Reporter: Stanley Hillner
> Assignee: Farah Juma
>
> I added JSF 1.2 support by follwing [this tutorial|https://community.jboss.org/wiki/StepsToAddAnyNewJSFImplementati...] and the sample project provided by Stan Silvert works fine. But when I deploy our own app I always get the following error message:
> {noformat}
> ERROR [request] UT005023: Exception handling request to /backoffice/login.faces: java.lang.NoSuchMethodError: javax.faces.context.FacesContext.getAttributes()Ljava/util/Map;
> [exec] at org.jboss.weld.jsf.ConversationAwareViewHandler.getActionURL(ConversationAwareViewHandler.java:103)
> [exec] at javax.faces.application.ViewHandlerWrapper.getActionURL(ViewHandlerWrapper.java:147)
> [exec] at com.sun.facelets.FaceletViewHandler.getActionURL(FaceletViewHandler.java:807)
> [exec] at org.apache.myfaces.shared_tomahawk.renderkit.html.HtmlRenderer.getActionUrl(HtmlRenderer.java:77)
> [exec] at org.apache.myfaces.custom.form.HtmlFormRenderer.getActionUrl(HtmlFormRenderer.java:45)
> [exec] at org.apache.myfaces.shared_tomahawk.renderkit.html.HtmlFormRendererBase.encodeBegin(HtmlFormRendererBase.java:102)
> [exec] at org.apache.myfaces.custom.form.HtmlFormRenderer.encodeBegin(HtmlFormRenderer.java:134)
> [exec] at javax.faces.component.UIComponentBase.encodeBegin(UIComponentBase.java:816)
> [exec] at javax.faces.component.UIComponent.encodeAll(UIComponent.java:928)
> [exec] at javax.faces.component.UIComponent.encodeAll(UIComponent.java:933)
> [exec] at com.sun.facelets.FaceletViewHandler.renderView(FaceletViewHandler.java:594)
> [exec] at com.sun.faces.lifecycle.RenderResponsePhase.execute(RenderResponsePhase.java:110)
> [exec] at com.sun.faces.lifecycle.Phase.doPhase(Phase.java:100)
> [exec] at com.sun.faces.lifecycle.LifecycleImpl.render(LifecycleImpl.java:139)
> [exec] at javax.faces.webapp.FacesServlet.service(FacesServlet.java:266)
> ...
> {noformat}
> This message indicates that the jsf-injection module still references a newer JSF API but not the JSF-1.2 API. I also had a look at the implementation of this module and I saw that the class ConversationAwareViewHandler which is included in the new jsf-injection module cannot work with JSF 1.2 since it calls methods from JSF 2.x.
> I also posted this issue [here|http://stackoverflow.com/questions/22758645/jsf-1-2-on-wildfly-8-fin...] and need a solution.
--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators
For more information on JIRA, see: http://www.atlassian.com/software/jira
12 years, 3 months
[JBoss JIRA] (WFLY-3215) JSF 1.2 on Wildfly 8 Final - weld-core-jsf is still referencing JSF 2.2 API
by Farah Juma (JIRA)
[ https://issues.jboss.org/browse/WFLY-3215?page=com.atlassian.jira.plugin.... ]
Farah Juma updated WFLY-3215:
-----------------------------
Component/s: CDI / Weld
> JSF 1.2 on Wildfly 8 Final - weld-core-jsf is still referencing JSF 2.2 API
> ---------------------------------------------------------------------------
>
> Key: WFLY-3215
> URL: https://issues.jboss.org/browse/WFLY-3215
> Project: WildFly
> Issue Type: Bug
> Security Level: Public(Everyone can see)
> Components: CDI / Weld, JSF
> Affects Versions: 8.0.0.Final
> Reporter: Stanley Hillner
> Assignee: Farah Juma
>
> I added JSF 1.2 support by follwing [this tutorial|https://community.jboss.org/wiki/StepsToAddAnyNewJSFImplementati...] and the sample project provided by Stan Silvert works fine. But when I deploy our own app I always get the following error message:
> {noformat}
> ERROR [request] UT005023: Exception handling request to /backoffice/login.faces: java.lang.NoSuchMethodError: javax.faces.context.FacesContext.getAttributes()Ljava/util/Map;
> [exec] at org.jboss.weld.jsf.ConversationAwareViewHandler.getActionURL(ConversationAwareViewHandler.java:103)
> [exec] at javax.faces.application.ViewHandlerWrapper.getActionURL(ViewHandlerWrapper.java:147)
> [exec] at com.sun.facelets.FaceletViewHandler.getActionURL(FaceletViewHandler.java:807)
> [exec] at org.apache.myfaces.shared_tomahawk.renderkit.html.HtmlRenderer.getActionUrl(HtmlRenderer.java:77)
> [exec] at org.apache.myfaces.custom.form.HtmlFormRenderer.getActionUrl(HtmlFormRenderer.java:45)
> [exec] at org.apache.myfaces.shared_tomahawk.renderkit.html.HtmlFormRendererBase.encodeBegin(HtmlFormRendererBase.java:102)
> [exec] at org.apache.myfaces.custom.form.HtmlFormRenderer.encodeBegin(HtmlFormRenderer.java:134)
> [exec] at javax.faces.component.UIComponentBase.encodeBegin(UIComponentBase.java:816)
> [exec] at javax.faces.component.UIComponent.encodeAll(UIComponent.java:928)
> [exec] at javax.faces.component.UIComponent.encodeAll(UIComponent.java:933)
> [exec] at com.sun.facelets.FaceletViewHandler.renderView(FaceletViewHandler.java:594)
> [exec] at com.sun.faces.lifecycle.RenderResponsePhase.execute(RenderResponsePhase.java:110)
> [exec] at com.sun.faces.lifecycle.Phase.doPhase(Phase.java:100)
> [exec] at com.sun.faces.lifecycle.LifecycleImpl.render(LifecycleImpl.java:139)
> [exec] at javax.faces.webapp.FacesServlet.service(FacesServlet.java:266)
> ...
> {noformat}
> This message indicates that the jsf-injection module still references a newer JSF API but not the JSF-1.2 API. I also had a look at the implementation of this module and I saw that the class ConversationAwareViewHandler which is included in the new jsf-injection module cannot work with JSF 1.2 since it calls methods from JSF 2.x.
> I also posted this issue [here|http://stackoverflow.com/questions/22758645/jsf-1-2-on-wildfly-8-fin...] and need a solution.
--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators
For more information on JIRA, see: http://www.atlassian.com/software/jira
12 years, 3 months
[JBoss JIRA] (WFLY-3215) JSF 1.2 on Wildfly 8 Final - weld-core-jsf is still referencing JSF 2.2 API
by Farah Juma (JIRA)
[ https://issues.jboss.org/browse/WFLY-3215?page=com.atlassian.jira.plugin.... ]
Farah Juma edited comment on WFLY-3215 at 4/3/14 1:48 PM:
----------------------------------------------------------
This is the Weld commit that modified the ConversationAwareViewHandler#getActionURL method so that it now references the FacesContext#getAttributes method, which doesn't exist in the JSF 1.2 version of FacesContext:
https://github.com/weld/core/commit/88f32d559a2061c822f89a47e5bbd6c85270c...
was (Author: fjuma):
This is the Weld commit that modified the ConversationAwareViewHandler#getActionURL method so that it now references the getAttributes method from FacesContext:
https://github.com/weld/core/commit/88f32d559a2061c822f89a47e5bbd6c85270c...
> JSF 1.2 on Wildfly 8 Final - weld-core-jsf is still referencing JSF 2.2 API
> ---------------------------------------------------------------------------
>
> Key: WFLY-3215
> URL: https://issues.jboss.org/browse/WFLY-3215
> Project: WildFly
> Issue Type: Bug
> Security Level: Public(Everyone can see)
> Components: JSF
> Affects Versions: 8.0.0.Final
> Reporter: Stanley Hillner
> Assignee: Farah Juma
>
> I added JSF 1.2 support by follwing [this tutorial|https://community.jboss.org/wiki/StepsToAddAnyNewJSFImplementati...] and the sample project provided by Stan Silvert works fine. But when I deploy our own app I always get the following error message:
> {noformat}
> ERROR [request] UT005023: Exception handling request to /backoffice/login.faces: java.lang.NoSuchMethodError: javax.faces.context.FacesContext.getAttributes()Ljava/util/Map;
> [exec] at org.jboss.weld.jsf.ConversationAwareViewHandler.getActionURL(ConversationAwareViewHandler.java:103)
> [exec] at javax.faces.application.ViewHandlerWrapper.getActionURL(ViewHandlerWrapper.java:147)
> [exec] at com.sun.facelets.FaceletViewHandler.getActionURL(FaceletViewHandler.java:807)
> [exec] at org.apache.myfaces.shared_tomahawk.renderkit.html.HtmlRenderer.getActionUrl(HtmlRenderer.java:77)
> [exec] at org.apache.myfaces.custom.form.HtmlFormRenderer.getActionUrl(HtmlFormRenderer.java:45)
> [exec] at org.apache.myfaces.shared_tomahawk.renderkit.html.HtmlFormRendererBase.encodeBegin(HtmlFormRendererBase.java:102)
> [exec] at org.apache.myfaces.custom.form.HtmlFormRenderer.encodeBegin(HtmlFormRenderer.java:134)
> [exec] at javax.faces.component.UIComponentBase.encodeBegin(UIComponentBase.java:816)
> [exec] at javax.faces.component.UIComponent.encodeAll(UIComponent.java:928)
> [exec] at javax.faces.component.UIComponent.encodeAll(UIComponent.java:933)
> [exec] at com.sun.facelets.FaceletViewHandler.renderView(FaceletViewHandler.java:594)
> [exec] at com.sun.faces.lifecycle.RenderResponsePhase.execute(RenderResponsePhase.java:110)
> [exec] at com.sun.faces.lifecycle.Phase.doPhase(Phase.java:100)
> [exec] at com.sun.faces.lifecycle.LifecycleImpl.render(LifecycleImpl.java:139)
> [exec] at javax.faces.webapp.FacesServlet.service(FacesServlet.java:266)
> ...
> {noformat}
> This message indicates that the jsf-injection module still references a newer JSF API but not the JSF-1.2 API. I also had a look at the implementation of this module and I saw that the class ConversationAwareViewHandler which is included in the new jsf-injection module cannot work with JSF 1.2 since it calls methods from JSF 2.x.
> I also posted this issue [here|http://stackoverflow.com/questions/22758645/jsf-1-2-on-wildfly-8-fin...] and need a solution.
--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators
For more information on JIRA, see: http://www.atlassian.com/software/jira
12 years, 3 months
[JBoss JIRA] (WFLY-3215) JSF 1.2 on Wildfly 8 Final - weld-core-jsf is still referencing JSF 2.2 API
by Farah Juma (JIRA)
[ https://issues.jboss.org/browse/WFLY-3215?page=com.atlassian.jira.plugin.... ]
Farah Juma commented on WFLY-3215:
----------------------------------
This is the Weld commit that modified the ConversationAwareViewHandler#getActionURL method so that it now references the getAttributes method from FacesContext:
https://github.com/weld/core/commit/88f32d559a2061c822f89a47e5bbd6c85270c...
> JSF 1.2 on Wildfly 8 Final - weld-core-jsf is still referencing JSF 2.2 API
> ---------------------------------------------------------------------------
>
> Key: WFLY-3215
> URL: https://issues.jboss.org/browse/WFLY-3215
> Project: WildFly
> Issue Type: Bug
> Security Level: Public(Everyone can see)
> Components: JSF
> Affects Versions: 8.0.0.Final
> Reporter: Stanley Hillner
> Assignee: Farah Juma
>
> I added JSF 1.2 support by follwing [this tutorial|https://community.jboss.org/wiki/StepsToAddAnyNewJSFImplementati...] and the sample project provided by Stan Silvert works fine. But when I deploy our own app I always get the following error message:
> {noformat}
> ERROR [request] UT005023: Exception handling request to /backoffice/login.faces: java.lang.NoSuchMethodError: javax.faces.context.FacesContext.getAttributes()Ljava/util/Map;
> [exec] at org.jboss.weld.jsf.ConversationAwareViewHandler.getActionURL(ConversationAwareViewHandler.java:103)
> [exec] at javax.faces.application.ViewHandlerWrapper.getActionURL(ViewHandlerWrapper.java:147)
> [exec] at com.sun.facelets.FaceletViewHandler.getActionURL(FaceletViewHandler.java:807)
> [exec] at org.apache.myfaces.shared_tomahawk.renderkit.html.HtmlRenderer.getActionUrl(HtmlRenderer.java:77)
> [exec] at org.apache.myfaces.custom.form.HtmlFormRenderer.getActionUrl(HtmlFormRenderer.java:45)
> [exec] at org.apache.myfaces.shared_tomahawk.renderkit.html.HtmlFormRendererBase.encodeBegin(HtmlFormRendererBase.java:102)
> [exec] at org.apache.myfaces.custom.form.HtmlFormRenderer.encodeBegin(HtmlFormRenderer.java:134)
> [exec] at javax.faces.component.UIComponentBase.encodeBegin(UIComponentBase.java:816)
> [exec] at javax.faces.component.UIComponent.encodeAll(UIComponent.java:928)
> [exec] at javax.faces.component.UIComponent.encodeAll(UIComponent.java:933)
> [exec] at com.sun.facelets.FaceletViewHandler.renderView(FaceletViewHandler.java:594)
> [exec] at com.sun.faces.lifecycle.RenderResponsePhase.execute(RenderResponsePhase.java:110)
> [exec] at com.sun.faces.lifecycle.Phase.doPhase(Phase.java:100)
> [exec] at com.sun.faces.lifecycle.LifecycleImpl.render(LifecycleImpl.java:139)
> [exec] at javax.faces.webapp.FacesServlet.service(FacesServlet.java:266)
> ...
> {noformat}
> This message indicates that the jsf-injection module still references a newer JSF API but not the JSF-1.2 API. I also had a look at the implementation of this module and I saw that the class ConversationAwareViewHandler which is included in the new jsf-injection module cannot work with JSF 1.2 since it calls methods from JSF 2.x.
> I also posted this issue [here|http://stackoverflow.com/questions/22758645/jsf-1-2-on-wildfly-8-fin...] and need a solution.
--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators
For more information on JIRA, see: http://www.atlassian.com/software/jira
12 years, 3 months
[JBoss JIRA] (WFLY-3173) Default number of DIST owners is too conservative
by Radoslav Husar (JIRA)
[ https://issues.jboss.org/browse/WFLY-3173?page=com.atlassian.jira.plugin.... ]
Radoslav Husar edited comment on WFLY-3173 at 4/3/14 1:45 PM:
--------------------------------------------------------------
Also in the model itself:
{code}
static final SimpleAttributeDefinition OWNERS = new SimpleAttributeDefinitionBuilder(ModelKeys.OWNERS, ModelType.INT, true)
.setXmlName(Attribute.OWNERS.getLocalName())
.setAllowExpression(true)
.setFlags(AttributeAccess.Flag.RESTART_ALL_SERVICES)
.setDefaultValue(new ModelNode().set(2))
.setValidator(new IntRangeValidator(1, true, true))
.build()
;
{code}
We explicitly specify the value (4) so we don't rely on a default, thus the transformer is *not needed*.
was (Author: rhusar):
Also in the model itself:
{code}
static final SimpleAttributeDefinition OWNERS = new SimpleAttributeDefinitionBuilder(ModelKeys.OWNERS, ModelType.INT, true)
.setXmlName(Attribute.OWNERS.getLocalName())
.setAllowExpression(true)
.setFlags(AttributeAccess.Flag.RESTART_ALL_SERVICES)
.setDefaultValue(new ModelNode().set(2))
.setValidator(new IntRangeValidator(1, true, true))
.build()
;
{code}
Thus, the transformer is *not needed*.
> Default number of DIST owners is too conservative
> -------------------------------------------------
>
> Key: WFLY-3173
> URL: https://issues.jboss.org/browse/WFLY-3173
> Project: WildFly
> Issue Type: Enhancement
> Security Level: Public(Everyone can see)
> Components: Clustering
> Affects Versions: 8.0.0.Final
> Reporter: Paul Ferraro
> Assignee: Radoslav Husar
> Fix For: 8.0.1.Final
>
>
> WildFly uses DIST by default using 4 owners, which is too conservative. I think we should lower this default value to 2, which is Infinispan's default value. We'll get a nice performance bump too.
> Don't forget to create transformers to handle the default value change for old model versions.
--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators
For more information on JIRA, see: http://www.atlassian.com/software/jira
12 years, 3 months
[JBoss JIRA] (WFLY-3173) Default number of DIST owners is too conservative
by Radoslav Husar (JIRA)
[ https://issues.jboss.org/browse/WFLY-3173?page=com.atlassian.jira.plugin.... ]
Radoslav Husar commented on WFLY-3173:
--------------------------------------
Also in the model itself:
{code}
static final SimpleAttributeDefinition OWNERS = new SimpleAttributeDefinitionBuilder(ModelKeys.OWNERS, ModelType.INT, true)
.setXmlName(Attribute.OWNERS.getLocalName())
.setAllowExpression(true)
.setFlags(AttributeAccess.Flag.RESTART_ALL_SERVICES)
.setDefaultValue(new ModelNode().set(2))
.setValidator(new IntRangeValidator(1, true, true))
.build()
;
{code}
Thus, the transformer is *not needed*.
> Default number of DIST owners is too conservative
> -------------------------------------------------
>
> Key: WFLY-3173
> URL: https://issues.jboss.org/browse/WFLY-3173
> Project: WildFly
> Issue Type: Enhancement
> Security Level: Public(Everyone can see)
> Components: Clustering
> Affects Versions: 8.0.0.Final
> Reporter: Paul Ferraro
> Assignee: Radoslav Husar
> Fix For: 8.0.1.Final
>
>
> WildFly uses DIST by default using 4 owners, which is too conservative. I think we should lower this default value to 2, which is Infinispan's default value. We'll get a nice performance bump too.
> Don't forget to create transformers to handle the default value change for old model versions.
--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators
For more information on JIRA, see: http://www.atlassian.com/software/jira
12 years, 3 months
[JBoss JIRA] (WFLY-3173) Default number of DIST owners is too conservative
by Radoslav Husar (JIRA)
[ https://issues.jboss.org/browse/WFLY-3173?page=com.atlassian.jira.plugin.... ]
Radoslav Husar commented on WFLY-3173:
--------------------------------------
The default in XSD is 2 already:
{code}
<xs:complexType name="distributed-cache">
<xs:complexContent>
<xs:extension base="tns:shared-state-cache">
<xs:attribute name="owners" type="xs:int" default="2">
<xs:annotation>
<xs:documentation>Number of cluster-wide replicas for each cache entry.</xs:documentation>
</xs:annotation>
</xs:attribute>
...
{code}
> Default number of DIST owners is too conservative
> -------------------------------------------------
>
> Key: WFLY-3173
> URL: https://issues.jboss.org/browse/WFLY-3173
> Project: WildFly
> Issue Type: Enhancement
> Security Level: Public(Everyone can see)
> Components: Clustering
> Affects Versions: 8.0.0.Final
> Reporter: Paul Ferraro
> Assignee: Radoslav Husar
> Fix For: 8.0.1.Final
>
>
> WildFly uses DIST by default using 4 owners, which is too conservative. I think we should lower this default value to 2, which is Infinispan's default value. We'll get a nice performance bump too.
> Don't forget to create transformers to handle the default value change for old model versions.
--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators
For more information on JIRA, see: http://www.atlassian.com/software/jira
12 years, 3 months