December 2015 - jboss-jira - Jboss List Archives

[JBoss JIRA] (WFLY-5917) numberOfLogicalViews not working

by Gabriel Vieira (JIRA)

[ https://issues.jboss.org/browse/WFLY-5917?page=com.atlassian.jira.plugin.... ] Gabriel Vieira updated WFLY-5917: --------------------------------- Steps to Reproduce: 1-Create a WEB project 2-Create a @ViewScoped and log @PostConstruct and @PreDestroy. 3-Set com.sun.faces.numberOfLogicalViews to 3 (or any other number) on web.xml. 4-Create a page that call the View created (Step 2). 5-You will notice that it will store view ultil max 25 (LRU map). was: 1-Create a WEB project 2-Create a @ViewScoped and log @PostConstruct and @PreDestroy. 3-Set com.sun.faces.numberOfLogicalViews to 3 (or any other number). 4-Create a page that call the View created (Step 2). 5-You will notice that it will store view ultil max 25 (LRU map). > numberOfLogicalViews not working > -------------------------------- > > Key: WFLY-5917 > URL: https://issues.jboss.org/browse/WFLY-5917 > Project: WildFly > Issue Type: Bug > Components: CDI / Weld, JSF > Affects Versions: 9.0.2.Final > Reporter: Gabriel Vieira > Assignee: Stuart Douglas > Labels: cdi, jsf22, wildfly > > Theres a bug in wildfly 9 Final > Even if a set on web.xml > {code:java} > <context-param> > <param-name>com.sun.faces.numberOfLogicalViews</param-name> > <param-value>3</param-value> > </context-param> > {code} > it keeps storing 25 views. > I tried @Named (CDI) and @ManagedBean and the problem persisted. > My workaround was use @ViewScoped from Omnifaces -- This message was sent by Atlassian JIRA (v6.4.11#64026)

10 years, 4 months

1
0
0 / 0

[JBoss JIRA] (WFLY-5917) numberOfLogicalViews not working

by Gabriel Vieira (JIRA)

[ https://issues.jboss.org/browse/WFLY-5917?page=com.atlassian.jira.plugin.... ] Gabriel Vieira updated WFLY-5917: --------------------------------- Steps to Reproduce: 1-Create a WEB project 2-Create a @ViewScoped and log @PostConstruct and @PreDestroy. 3-Set com.sun.faces.numberOfLogicalViews to 3 (or any other number). 4-Create a page that call the View created (Step 2). 5-You will notice that it will store view ultil max 25 (LRU map). was: 1-Create a WEB project 2-Create a @ViewScoped and log @PostConstruct and @PreDestroy to log it. 3-Set com.sun.faces.numberOfLogicalViews to 3 (or any other number). 4-Create a page that call the View created (Step 2). 5-You will notice that it will store view ultil max 25 (LRU map). > numberOfLogicalViews not working > -------------------------------- > > Key: WFLY-5917 > URL: https://issues.jboss.org/browse/WFLY-5917 > Project: WildFly > Issue Type: Bug > Components: CDI / Weld, JSF > Affects Versions: 9.0.2.Final > Reporter: Gabriel Vieira > Assignee: Stuart Douglas > Labels: cdi, jsf22, wildfly > > Theres a bug in wildfly 9 Final > Even if a set on web.xml > {code:java} > <context-param> > <param-name>com.sun.faces.numberOfLogicalViews</param-name> > <param-value>3</param-value> > </context-param> > {code} > it keeps storing 25 views. > I tried @Named (CDI) and @ManagedBean and the problem persisted. > My workaround was use @ViewScoped from Omnifaces -- This message was sent by Atlassian JIRA (v6.4.11#64026)

10 years, 4 months

1
0
0 / 0

[JBoss JIRA] (WFLY-5917) numberOfLogicalViews not working

by Gabriel Vieira (JIRA)

Gabriel Vieira created WFLY-5917: ------------------------------------ Summary: numberOfLogicalViews not working Key: WFLY-5917 URL: https://issues.jboss.org/browse/WFLY-5917 Project: WildFly Issue Type: Bug Components: CDI / Weld, JSF Affects Versions: 9.0.2.Final Reporter: Gabriel Vieira Assignee: Stuart Douglas Theres a bug in wildfly 9 Final Even if a set on web.xml {code:java} <context-param> <param-name>com.sun.faces.numberOfLogicalViews</param-name> <param-value>3</param-value> </context-param> {code} it keeps storing 25 views. I tried @Named (CDI) and @ManagedBean and the problem persisted. My workaround was use @ViewScoped from Omnifaces -- This message was sent by Atlassian JIRA (v6.4.11#64026)

10 years, 4 months

1
0
0 / 0

[JBoss JIRA] (WFLY-5915) Upgrade Jackson from 2.5.4 to 2.6.3 as used in RESTEasy 3.0.14.Final

by Frank Langelage (JIRA)

[ https://issues.jboss.org/browse/WFLY-5915?page=com.atlassian.jira.plugin.... ] Frank Langelage commented on WFLY-5915: --------------------------------------- Duplicate of https://issues.jboss.org/browse/WFLY-5911. > Upgrade Jackson from 2.5.4 to 2.6.3 as used in RESTEasy 3.0.14.Final > -------------------------------------------------------------------- > > Key: WFLY-5915 > URL: https://issues.jboss.org/browse/WFLY-5915 > Project: WildFly > Issue Type: Bug > Components: REST > Affects Versions: 10.0.0.CR5 > Reporter: Juergen Zimmermann > Assignee: Stuart Douglas > > RESTEasy 3.0.14.Final is upgraded to Jackson 2.6.3. However, WildFly is still providing the old Jackson release 2.5.4. > See https://github.com/resteasy/Resteasy/blob/master/jaxrs/pom.xml#L59 -- This message was sent by Atlassian JIRA (v6.4.11#64026)

10 years, 4 months

1
0
0 / 0

[JBoss JIRA] (WFLY-5916) jackson-datatype-jsr310 and jackson-datatype-jdk8 are missing

by Juergen Zimmermann (JIRA)

Juergen Zimmermann created WFLY-5916: ---------------------------------------- Summary: jackson-datatype-jsr310 and jackson-datatype-jdk8 are missing Key: WFLY-5916 URL: https://issues.jboss.org/browse/WFLY-5916 Project: WildFly Issue Type: Bug Components: REST Affects Versions: 10.0.0.CR5 Reporter: Juergen Zimmermann Assignee: Stuart Douglas WildFly doesn't provide jackson-datatype-jsr310 and jackson-datatype-jdk8 for RESTEasy. jackson-datatype-jsr310 supports the new JDK 8 time API, and jackson-datatype-jdk8 supports the new JDK 8 Optional type. The GAVs are: com.fasterxml.jackson.datatype:jackson-datatype-jsr310:2.6.3 com.fasterxml.jackson.datatype:jackson-datatype-jdk8:2.6.3 The latest Jackson GA version is 2.6.4. Please see also https://issues.jboss.org/browse/WFLY-5915. -- This message was sent by Atlassian JIRA (v6.4.11#64026)

10 years, 4 months

1
0
0 / 0

[JBoss JIRA] (WFLY-5915) Upgrade Jackson from 2.5.4 to 2.6.3 as used in RESTEasy 3.0.14.Final

by Juergen Zimmermann (JIRA)

Juergen Zimmermann created WFLY-5915: ---------------------------------------- Summary: Upgrade Jackson from 2.5.4 to 2.6.3 as used in RESTEasy 3.0.14.Final Key: WFLY-5915 URL: https://issues.jboss.org/browse/WFLY-5915 Project: WildFly Issue Type: Bug Components: REST Affects Versions: 10.0.0.CR5 Reporter: Juergen Zimmermann Assignee: Stuart Douglas RESTEasy 3.0.14.Final is upgraded to Jackson 2.6.3. However, WildFly is still providing the old Jackson release 2.5.4. See https://github.com/resteasy/Resteasy/blob/master/jaxrs/pom.xml#L59 -- This message was sent by Atlassian JIRA (v6.4.11#64026)

10 years, 4 months

1
0
0 / 0

[JBoss JIRA] (AS7-424) Implement IIOP support for EJB 3

by JBoss Crazzzzzzy (JIRA)

[ https://issues.jboss.org/browse/AS7-424?page=com.atlassian.jira.plugin.sy... ] JBoss Crazzzzzzy commented on AS7-424: -------------------------------------- Hi, Can you please provide example of using EJB3 with IIOP. How to access the EJB3 with IIOP/Corba.? Thanks > Implement IIOP support for EJB 3 > -------------------------------- > > Key: AS7-424 > URL: https://issues.jboss.org/browse/AS7-424 > Project: Application Server 7 > Issue Type: Task > Components: EJB > Reporter: Carlo de Wolf > Assignee: Stuart Douglas > Priority: Critical > Fix For: 7.1.0.Beta1 > > -- This message was sent by Atlassian JIRA (v6.4.11#64026)

10 years, 4 months

1
0
0 / 0

[JBoss JIRA] (DROOLS-1016) Too much memory consumption while running code on drools6.

by Vivek Hingorani (JIRA)

[ https://issues.jboss.org/browse/DROOLS-1016?page=com.atlassian.jira.plugi... ] Vivek Hingorani updated DROOLS-1016: ------------------------------------ Summary: Too much memory consumption while running code on drools6. (was: Too much memory consumpition while running code on drools6.) > Too much memory consumption while running code on drools6. > ---------------------------------------------------------- > > Key: DROOLS-1016 > URL: https://issues.jboss.org/browse/DROOLS-1016 > Project: Drools > Issue Type: Bug > Components: core engine > Affects Versions: 6.2.0.Final > Reporter: Vivek Hingorani > Assignee: Mario Fusco > > The memory usage on drools6 is far more then drools 5. Can we run the drools6 code with Rete algorithm? > We recently migrated our project from Drools 5.3.0.Final version to Drools 6.2.0.Final version. In production we can see a significant increase in the memory consumption per node. we are using java 1.7. We increased the permgen space as well for drools6 from 0.5 GB to 1 GB but still the increase is too much. Is there any solution for the same. > Drools5 memory usage was 0.5GB per node with 0.5GB permgen space > Drools6 memory usage is 1.3GB per node with 1GB permgen space. > Node here is a jvm as we are using oracle coherence. > If further details are needed , let me know. -- This message was sent by Atlassian JIRA (v6.4.11#64026)

10 years, 4 months

1
0
0 / 0

[JBoss JIRA] (DROOLS-1016) Too much memory consumpition while running code on drools6.

by Vivek Hingorani (JIRA)

Vivek Hingorani created DROOLS-1016: --------------------------------------- Summary: Too much memory consumpition while running code on drools6. Key: DROOLS-1016 URL: https://issues.jboss.org/browse/DROOLS-1016 Project: Drools Issue Type: Bug Components: core engine Affects Versions: 6.2.0.Final Reporter: Vivek Hingorani Assignee: Mario Fusco The memory usage on drools6 is far more then drools 5. Can we run the drools6 code with Rete algorithm? We recently migrated our project from Drools 5.3.0.Final version to Drools 6.2.0.Final version. In production we can see a significant increase in the memory consumption per node. we are using java 1.7. We increased the permgen space as well for drools6 from 0.5 GB to 1 GB but still the increase is too much. Is there any solution for the same. Drools5 memory usage was 0.5GB per node with 0.5GB permgen space Drools6 memory usage is 1.3GB per node with 1GB permgen space. Node here is a jvm as we are using oracle coherence. If further details are needed , let me know. -- This message was sent by Atlassian JIRA (v6.4.11#64026)

10 years, 4 months

1
0
0 / 0

[JBoss JIRA] (WFCORE-591) revertReloadRequired() throws a NPE is reloadRequired has not been called

by RH Bugzilla Integration (JIRA)

[ https://issues.jboss.org/browse/WFCORE-591?page=com.atlassian.jira.plugin... ] RH Bugzilla Integration updated WFCORE-591: ------------------------------------------- Bugzilla References: https://bugzilla.redhat.com/show_bug.cgi?id=1294591 Bugzilla Update: Perform > revertReloadRequired() throws a NPE is reloadRequired has not been called > ------------------------------------------------------------------------- > > Key: WFCORE-591 > URL: https://issues.jboss.org/browse/WFCORE-591 > Project: WildFly Core > Issue Type: Bug > Components: Domain Management > Affects Versions: 1.0.0.Alpha19 > Reporter: Jeff Mesnil > Assignee: Jeff Mesnil > Fix For: 1.0.0.Beta1 > > > If an operation step handler calls org.jboss.as.controller.OperationContext#revertReloadRequired() when org.jboss.as.controller.OperationContext#reloadRequired() has not been called, it throws a NPE: > {noformat} > java.lang.NullPointerException > at org.jboss.as.controller.ControlledProcessState.revertReloadRequired(ControlledProcessState.java:181) > at org.jboss.as.controller.AbstractOperationContext.revertReloadRequired(AbstractOperationContext.java:1037) > at org.jboss.as.controller.test.RevertReloadRequiredTestCase$TestResourceAddHandler.rollbackRuntime(RevertReloadRequiredTestCase.java:98) > at org.jboss.as.controller.AbstractAddStepHandler$1$1.handleRollback(AbstractAddStepHandler.java:133) > at org.jboss.as.controller.AbstractOperationContext$RollbackDelegatingResultHandler.handleResult(AbstractOperationContext.java:1419) > at org.jboss.as.controller.AbstractOperationContext$Step.invokeResultHandler(AbstractOperationContext.java:1385) > at org.jboss.as.controller.AbstractOperationContext$Step.handleResult(AbstractOperationContext.java:1367) > at org.jboss.as.controller.AbstractOperationContext$Step.finalizeInternal(AbstractOperationContext.java:1323) > at org.jboss.as.controller.AbstractOperationContext$Step.finalizeStep(AbstractOperationContext.java:1283) > at org.jboss.as.controller.AbstractOperationContext$Step.access$300(AbstractOperationContext.java:1172) > at org.jboss.as.controller.AbstractOperationContext.finishStep(AbstractOperationContext.java:929) > at org.jboss.as.controller.AbstractOperationContext.executeStep(AbstractOperationContext.java:877) > at org.jboss.as.controller.AbstractOperationContext.doCompleteStep(AbstractOperationContext.java:601) > at org.jboss.as.controller.AbstractOperationContext.completeStepInternal(AbstractOperationContext.java:354) > at org.jboss.as.controller.AbstractOperationContext.executeOperation(AbstractOperationContext.java:330) > at org.jboss.as.controller.OperationContextImpl.executeOperation(OperationContextImpl.java:1182) > at org.jboss.as.controller.ModelControllerImpl.internalExecute(ModelControllerImpl.java:362) > at org.jboss.as.controller.ModelControllerImpl.execute(ModelControllerImpl.java:205) > {noformat} > The NPE is caused by this.activeStep.restartStamp field which is set only when reloadRequired() (or restartRequired()) is called. > My OSH may call reloadRequired() or not depending on some runtime state and I could add some logic to make sure I call > I can fix my handle to check that I call context.revertReloadRequired() only I had previously called reloadRequired () first. > However, in order to make the OperationContext more robust, I think that the revertReloadRequired() method should instead be a no-op if there is no reload required. -- This message was sent by Atlassian JIRA (v6.4.11#64026)

10 years, 4 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 December 2015