April 2013 - jboss-jira - Jboss List Archives

[JBoss JIRA] (DROOLS-65) Local Cache is not updated, case client is started before the server

by RH Bugzilla Integration (JIRA)

[ https://issues.jboss.org/browse/DROOLS-65?page=com.atlassian.jira.plugin.... ] RH Bugzilla Integration commented on DROOLS-65: ----------------------------------------------- Marek Winkler <mwinkler(a)redhat.com> made a comment on [bug 917787|https://bugzilla.redhat.com/show_bug.cgi?id=917787] Verified on 5.3.1.BRMS-P02. > Local Cache is not updated, case client is started before the server > -------------------------------------------------------------------- > > Key: DROOLS-65 > URL: https://issues.jboss.org/browse/DROOLS-65 > Project: Drools > Issue Type: Bug > Security Level: Public(Everyone can see) > Environment: BRMS 5.3.1 > Reporter: Alessandro Lazarotti > Assignee: Mark Proctor > Fix For: 6.0.0.Alpha1 > > > Local Cache is not updated, case client is started before the server > 1. Start Guvnor > 2. Any regular client application consumes some package with local cache configured (drools.resource.urlcache) > 3. Stop client and server > 4. Restart the client (it will work consuming data from loca cache) > 5. Restart the server and changes a rule from the package used by client application > 6. BUild the package > 7. Local cache still consume the package from the local cache which is never synchronized with the server > It works as expected case only the server is restarted or if server starts before the client. -- 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, 9 months

1
0
0 / 0

[JBoss JIRA] (AS7-5970) RichFaces Showcase portlet is unable to switch skins

by Stan Silvert (JIRA)

[ https://issues.jboss.org/browse/AS7-5970?page=com.atlassian.jira.plugin.s... ] Stan Silvert commented on AS7-5970: ----------------------------------- Are you guys satisfied that this is fixed now that JAVASERVERFACES-2609 is done? Upstream fix should be integrated now. Can we close this? > RichFaces Showcase portlet is unable to switch skins > ---------------------------------------------------- > > Key: AS7-5970 > URL: https://issues.jboss.org/browse/AS7-5970 > Project: Application Server 7 > Issue Type: Bug > Components: JSF > Affects Versions: 7.1.3.Final (EAP) > Reporter: Ken Finnigan > Assignee: Stan Silvert > > The following exception is thrown when the user changes skins for the second time immediately after changing the skin for the first time: > {noformat} > Caused by: javax.faces.FacesException: Cannot remove the same component twice: pbG9dea276d_2dee9e_2d4150_2dad91_2d22255b5a57d2_j_id1:j_idt444 > at com.sun.faces.context.StateContext$AddRemoveListener.handleAddRemoveWithAutoPrune(StateContext.java:489) [jsf-impl-2.1.13-redhat-1.jar:2.1.13-redhat-1] > at com.sun.faces.context.StateContext$AddRemoveListener.handleRemove(StateContext.java:371) [jsf-impl-2.1.13-redhat-1.jar:2.1.13-redhat-1] > at com.sun.faces.context.StateContext$AddRemoveListener.processEvent(StateContext.java:334) [jsf-impl-2.1.13-redhat-1.jar:2.1.13-redhat-1] > at javax.faces.event.SystemEvent.processListener(SystemEvent.java:106) [jboss-jsf-api_2.1_spec-2.0.7.Final-redhat-1.jar:2.0.7.Final-redhat-1] > {noformat} > This error manifests due to the Portlet Bridge needing to retain the UIViewRoot from JSF between Portlet Requests, which causes the list of component tree actions, ie. adding and removing, to be retained making JSF think that it's trying to remove a component that was actually removed in a previous request. > This has been raised as http://java.net/jira/browse/JAVASERVERFACES-2609, but wanted to raise this as a tracker so that when that fix is available it can be incorporated. -- 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, 9 months

1
0
0 / 0

[JBoss JIRA] (JBAS-8861) JSF Flash doesn't return data in the right order

by Stan Silvert (JIRA)

[ https://issues.jboss.org/browse/JBAS-8861?page=com.atlassian.jira.plugin.... ] Stan Silvert resolved JBAS-8861. -------------------------------- Resolution: Out of Date > JSF Flash doesn't return data in the right order > ------------------------------------------------ > > Key: JBAS-8861 > URL: https://issues.jboss.org/browse/JBAS-8861 > Project: Application Server 3 4 5 and 6 > Issue Type: Bug > Security Level: Public(Everyone can see) > Components: JSF > Affects Versions: 6.0.0.Final > Environment: Redhat Linux 5.5 > Reporter: Jboss fan99 > Assignee: Stan Silvert > Fix For: No Release > > Attachments: login.xhtml, LoginBackingBean.java, Referer.xhtml > > > Data stored in JSF flash during a request is not returned in the next request. It's returned during the 3rd request. I have a very simple test to verify this behavior. > LoginBackingBean has two methods which are called in 2 subsequent requests. Variable kept in flash memory during request 1 doesn't return in request 2 but in request 3. > 3 small files required to reproduce are attached. First referer.xhtml should be opened in a JSF app, then its login button calls doLogin method and takes you to Login.xhtml file. Now "Simulate Login" button need to be clicked twice to get the variable. -- 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, 9 months

1
0
0 / 0

[JBoss JIRA] (JBAS-8475) Add Mojarra 2.0.4 workaround information to the AS/JSK integration wiki

by Stan Silvert (JIRA)

[ https://issues.jboss.org/browse/JBAS-8475?page=com.atlassian.jira.plugin.... ] Stan Silvert resolved JBAS-8475. -------------------------------- Resolution: Out of Date > Add Mojarra 2.0.4 workaround information to the AS/JSK integration wiki > ----------------------------------------------------------------------- > > Key: JBAS-8475 > URL: https://issues.jboss.org/browse/JBAS-8475 > Project: Application Server 3 4 5 and 6 > Issue Type: Task > Security Level: Public(Everyone can see) > Components: Integration, JSF > Affects Versions: 6.0.0.M4 > Reporter: Jay Balunas > Assignee: Stan Silvert > > See JBAS-8375 for the details. > If users want to use JSF RI 2.0.4. -- 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, 9 months

1
0
0 / 0

[JBoss JIRA] (JBAS-8099) Lazy-load JSF configurations in JSF Deployer

by Stan Silvert (JIRA)

[ https://issues.jboss.org/browse/JBAS-8099?page=com.atlassian.jira.plugin.... ] Stan Silvert resolved JBAS-8099. -------------------------------- Resolution: Out of Date > Lazy-load JSF configurations in JSF Deployer > -------------------------------------------- > > Key: JBAS-8099 > URL: https://issues.jboss.org/browse/JBAS-8099 > Project: Application Server 3 4 5 and 6 > Issue Type: Task > Security Level: Public(Everyone can see) > Components: JSF > Affects Versions: 6.0.0.M4 > Reporter: Stan Silvert > Assignee: Stan Silvert > Priority: Minor > Fix For: No Release > > > The JSF configurations/implementations are loaded at startup by the JSF Deployer. This could improve startup a tiny bit if each were loaded on demand. -- 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, 9 months

1
0
0 / 0

[JBoss JIRA] (AS7-6573) JSR-236 Java EE 7 concurrency support parent issue

by David Lloyd (JIRA)

[ https://issues.jboss.org/browse/AS7-6573?page=com.atlassian.jira.plugin.s... ] David Lloyd commented on AS7-6573: ---------------------------------- Please open a separate top-level feature request JIRA for that. Thanks. > JSR-236 Java EE 7 concurrency support parent issue > -------------------------------------------------- > > Key: AS7-6573 > URL: https://issues.jboss.org/browse/AS7-6573 > Project: Application Server 7 > Issue Type: Enhancement > Components: EE > Reporter: David Lloyd > Assignee: David Lloyd > Fix For: 8.0.0.Alpha1 > > > Parent task for JSR-236 subtasks. Please resolve AS7-6430 only when this issue is resolved. -- 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, 9 months

1
0
0 / 0

[JBoss JIRA] (JBAS-8751) javax.faces.INTERPRET_EMPTY_STRING_SUBMITTED_VALUES_AS_NULL not honored

by Stan Silvert (JIRA)

[ https://issues.jboss.org/browse/JBAS-8751?page=com.atlassian.jira.plugin.... ] Stan Silvert resolved JBAS-8751. -------------------------------- Resolution: Rejected Closing as per AS7-5310 > javax.faces.INTERPRET_EMPTY_STRING_SUBMITTED_VALUES_AS_NULL not honored > ----------------------------------------------------------------------- > > Key: JBAS-8751 > URL: https://issues.jboss.org/browse/JBAS-8751 > Project: Application Server 3 4 5 and 6 > Issue Type: Bug > Security Level: Public(Everyone can see) > Components: JSF > Affects Versions: 6.0.0.CR1 > Reporter: Nicklas Karlsson > Assignee: Stan Silvert > Fix For: No Release > > > Given a model like > @javax.enterprise.inject.Model > public class Model > { > private String data; > public String getData() > { > return data; > } > public void setData(String data) > { > System.out.println("set data to " + data); > this.data = data; > } > } > and a view like > <h:form> > <h:inputText id="field" value="#{model.data}"/> > <h:commandButton value="!"/> > </h:form> > an empty value is submitted even with > <context-param> > <param-name>javax.faces.INTERPRET_EMPTY_STRING_SUBMITTED_VALUES_AS_NULL</param-name> > <param-value>true</param-value> > </context-param> > Debugging the application shows that the emptyStringIsNull of the component is true. > even with a @FacesConverter(forClass=String.class) which is correctly run and doing a setSubmittedValue(null), the model still sees a "" instead of a null > Tested to work correctly on a GF 3.0.1 -- 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, 9 months

1
0
0 / 0

[JBoss JIRA] (AS7-6573) JSR-236 Java EE 7 concurrency support parent issue

by Philippe Marschall (JIRA)

[ https://issues.jboss.org/browse/AS7-6573?page=com.atlassian.jira.plugin.s... ] Philippe Marschall commented on AS7-6573: ----------------------------------------- It would be great if AS8 went farther than the spec and provided a {{java.util.concurrent.ForkJoinPool}} and a {{java.util.concurrent.ForkJoinPool.ForkJoinWorkerThreadFactory}}. These don't have to (and probably shouldn't) preserve the context (see also http://java.net/projects/concurrency-ee-spec/lists/jsr236-experts/archive...). The advantage of this instead of manually creating a {{ForkJoinPool}} would be that it can be configured, managed and monitored in the server (and that threads are traditionally managed by the server). I'm well aware that this is unspecified behaviour but so is Infinispan in AS7 and AS8 since JSR-107 again didn't make it. Should I open a separate subtask for this? > JSR-236 Java EE 7 concurrency support parent issue > -------------------------------------------------- > > Key: AS7-6573 > URL: https://issues.jboss.org/browse/AS7-6573 > Project: Application Server 7 > Issue Type: Enhancement > Components: EE > Reporter: David Lloyd > Assignee: David Lloyd > Fix For: 8.0.0.Alpha1 > > > Parent task for JSR-236 subtasks. Please resolve AS7-6430 only when this issue is resolved. -- 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, 9 months

1
0
0 / 0

[JBoss JIRA] (JBEE-120) JBoss build of jsf api contains incorrect xml header

by Stan Silvert (JIRA)

[ https://issues.jboss.org/browse/JBEE-120?page=com.atlassian.jira.plugin.s... ] Stan Silvert resolved JBEE-120. ------------------------------- Resolution: Out of Date Closing as out of date. We are dropping JSF 1.2 from AS8. Since this doesn't cause any operational problems it doesn't seem worth fixing. If you disagree, please let me know and we can reopen. > JBoss build of jsf api contains incorrect xml header > ---------------------------------------------------- > > Key: JBEE-120 > URL: https://issues.jboss.org/browse/JBEE-120 > Project: JBoss JavaEE Spec APIs > Issue Type: Bug > Components: general > Reporter: Paul Gier > Assignee: Stan Silvert > Fix For: JavaEE 5 Spec APIs - Maint > > > The JBoss rebuild of the jsf api jar contains an incorrect xml header missing the namespace. > https://repository.jboss.org/nexus/content/groups/public/javax/faces/jsf-... > Current header: > {code:xml} > <project xsi:schemaLocation="http://maven.apache.org/POM/4.0.0 http://maven.apache.org/xsd/maven-4.0.0.xsd"> > {code} > Correct header: > {code:xml} > <project xmlns="http://maven.apache.org/POM/4.0.0" xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance" > xsi:schemaLocation="http://maven.apache.org/POM/4.0.0 http://maven.apache.org/maven-v4_0_0.xsd"> > {code} -- 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, 9 months

1
0
0 / 0

[JBoss JIRA] (AS7-6790) Multi-JSF doesn't understand new modules structure

by Stan Silvert (JIRA)

[ https://issues.jboss.org/browse/AS7-6790?page=com.atlassian.jira.plugin.s... ] Stan Silvert commented on AS7-6790: ----------------------------------- Long term fix will be to eliminate directory scanning when some feature like MODULES-151 is implemented. > Multi-JSF doesn't understand new modules structure > -------------------------------------------------- > > Key: AS7-6790 > URL: https://issues.jboss.org/browse/AS7-6790 > Project: Application Server 7 > Issue Type: Bug > Components: JSF > Affects Versions: EAP 6.1.0.Alpha (7.2.0.Final) > Reporter: Stan Silvert > Assignee: Stan Silvert > > With the new modules structure, Multi-JSF is looking for JSF implementations in the root of the modules directory instead of in modules/system/layers/base. The reason is that Multi-JSF relies on the module.path property which points to the root by default. > The workaround is to go ahead and install the new JSF impl wherever you wish and add that directory to JBOSS_MODULEPATH in the startup script. > See https://community.jboss.org/wiki/DesignOfAS7Multi-JSFFeature#comment-11789 -- 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, 9 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 April 2013