[JBoss JIRA] (RF-11592) fileUpload component incompatible with Apache MyFaces Orchestra conversation scope
by Brian Leathem (JIRA)
[ https://issues.jboss.org/browse/RF-11592?page=com.atlassian.jira.plugin.s... ]
Brian Leathem updated RF-11592:
-------------------------------
Summary: fileUpload component incompatible with Apache MyFaces Orchestra conversation scope (was: RichFaces 4.1 Milestone changes for fileUpload component incompatible with Apache MyFaces Orchestra conversation scope)
> fileUpload component incompatible with Apache MyFaces Orchestra conversation scope
> ----------------------------------------------------------------------------------
>
> Key: RF-11592
> URL: https://issues.jboss.org/browse/RF-11592
> Project: RichFaces
> Issue Type: Bug
> Security Level: Public(Everyone can see)
> Components: component-input
> Affects Versions: 4.1.0.Milestone1, 4.1.0.Milestone2, 4.1.0.Milestone3
> Environment: Mojarra 2.1.3, JBoss AS 5.0.1, Apache MyFaces Orchestra 1.4, Spring 3.0.4
> Reporter: Joshua Brookes
> Labels: fileUpload, multipart/form-data, orchestra, regression, richfaces, richfaces4
> Fix For: 5-Tracking
>
> Attachments: fileUploadWeb.zip, server.log
>
>
> There is a compatibility issue with recent changes in RichFaces 4.1 Milestone 1 and Apache MyFaces Orchestra conversation scope feature. When including the Orchestra jar in the application the fileUpload component stops working. Orchestra bundles a faces-config.xml that enables 2 FacesContext Factories and multiple PhaseListeners. This did not pose a problem with RichFaces 4.0.0.Final.
> Here is a stacktrace that shows the error:
> {code}
> Oct 25, 2011 11:45:01 AM org.richfaces.request.MultipartRequest25 parseIfNecessary
> SEVERE: Exception parsing multipart request: Request prolog cannot be read
> org.richfaces.exception.FileUploadException: Exception parsing multipart request: Request prolog cannot be read
> at org.richfaces.request.MultipartRequestParser.parse(MultipartRequestParser.java:156)
> at org.richfaces.request.MultipartRequest25.parseIfNecessary(MultipartRequest25.java:77)
> at org.richfaces.request.MultipartRequest25.getParameter(MultipartRequest25.java:114)
> at com.sun.faces.context.RequestParameterMap.containsKey(RequestParameterMap.java:99)
> at java.util.Collections$UnmodifiableMap.containsKey(Collections.java:1280)
> at org.apache.myfaces.orchestra.frameworkAdapter.jsf.JsfFrameworkAdapter.containsRequestParameterAttribute(JsfFrameworkAdapter.java:105)
> at org.apache.myfaces.orchestra.conversation.ConversationManager.findConversationContextId(ConversationManager.java:169)
> at org.apache.myfaces.orchestra.conversation.ConversationManager.getCurrentRootConversationContext(ConversationManager.java:580)
> at org.apache.myfaces.orchestra.lib.jsf.ContextLockRequestHandler.init(ContextLockRequestHandler.java:87)
> at org.apache.myfaces.orchestra.lib.jsf.OrchestraFacesContextFactory$1.<init>(OrchestraFacesContextFactory.java:122)
> at org.apache.myfaces.orchestra.lib.jsf.OrchestraFacesContextFactory.getFacesContext(OrchestraFacesContextFactory.java:103)
> at org.apache.myfaces.orchestra.requestParameterProvider.jsf.RequestParameterFacesContextFactory.getFacesContext(RequestParameterFacesContextFactory.java:93)
> at org.richfaces.context.FileUploadFacesContextFactory.getFacesContext(FileUploadFacesContextFactory.java:136)
> at com.sun.faces.context.InjectionFacesContextFactory.getFacesContext(InjectionFacesContextFactory.java:121)
> at javax.faces.webapp.FacesServlet.service(FacesServlet.java:583)
> at org.apache.catalina.core.ApplicationFilterChain.internalDoFilter(ApplicationFilterChain.java:290)
> at org.apache.catalina.core.ApplicationFilterChain.doFilter(ApplicationFilterChain.java:206)
> at org.apache.catalina.core.ApplicationDispatcher.invoke(ApplicationDispatcher.java:638)
> at org.apache.catalina.core.ApplicationDispatcher.processRequest(ApplicationDispatcher.java:446)
> at org.apache.catalina.core.ApplicationDispatcher.doForward(ApplicationDispatcher.java:382)
> at org.apache.catalina.core.ApplicationDispatcher.forward(ApplicationDispatcher.java:310)
> at org.apache.catalina.core.StandardHostValve.custom(StandardHostValve.java:416)
> at org.apache.catalina.core.StandardHostValve.status(StandardHostValve.java:342)
> at org.apache.catalina.core.StandardHostValve.throwable(StandardHostValve.java:286)
> at org.apache.catalina.core.StandardHostValve.invoke(StandardHostValve.java:141)
> at org.apache.catalina.valves.ErrorReportValve.invoke(ErrorReportValve.java:102)
> at org.jboss.web.tomcat.service.jca.CachedConnectionValve.invoke(CachedConnectionValve.java:158)
> at org.apache.catalina.core.StandardEngineValve.invoke(StandardEngineValve.java:109)
> at org.apache.catalina.connector.CoyoteAdapter.service(CoyoteAdapter.java:330)
> at org.apache.coyote.http11.Http11Processor.process(Http11Processor.java:829)
> at org.apache.coyote.http11.Http11Protocol$Http11ConnectionHandler.process(Http11Protocol.java:598)
> at org.apache.tomcat.util.net.JIoEndpoint$Worker.run(JIoEndpoint.java:447)
> at java.lang.Thread.run(Thread.java:619)
> Caused by: java.io.IOException: Request prolog cannot be read
> at org.richfaces.request.MultipartRequestParser.readProlog(MultipartRequestParser.java:270)
> at org.richfaces.request.MultipartRequestParser.initialize(MultipartRequestParser.java:172)
> at org.richfaces.request.MultipartRequestParser.parse(MultipartRequestParser.java:148)
> ... 32 more
> {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
10 years, 8 months
[JBoss JIRA] (RF-11469) autocomplete method does not resolve bean if ui:included
by Brian Leathem (JIRA)
[ https://issues.jboss.org/browse/RF-11469?page=com.atlassian.jira.plugin.s... ]
Brian Leathem updated RF-11469:
-------------------------------
Labels: (was: waiting_on_user)
> autocomplete method does not resolve bean if ui:included
> --------------------------------------------------------
>
> Key: RF-11469
> URL: https://issues.jboss.org/browse/RF-11469
> Project: RichFaces
> Issue Type: Bug
> Security Level: Public(Everyone can see)
> Components: component-input
> Affects Versions: 4.0.0.Final
> Reporter: u j
> Assignee: Lukáš Fryč
> Priority: Minor
> Attachments: RF-11469.zip
>
> Original Estimate: 45 minutes
> Remaining Estimate: 45 minutes
>
> A bean parameter in the autocomplete method is not resolved if the rich:autocomplete is part of a ui:include.
> {code}
> <ui:include src="/searchlocation.xhtml">
> <ui:param name="bean" value="#{searchBean}" />
> </ui:include>
> {code}
> searchlocation.xhtml contains:
> {code}
> <rich:autocomplete id="cityName" mode="ajax" value="#{bean.cityName}" autocompleteMethod="#{bean.suggestCities}" />
> {code}
> The value binding works, but the binding in the autocompleteMethod gives:
> {code}
> 15:26:15,809 SEVERE [org.richfaces.log.Renderkit] (ajp-127.0.0.1-127.0.0.1-8009-1) Target Unreachable, identifier 'bean' resolved to null: javax.el.PropertyNotFoundException: Target Unreachable, identifier 'bean' resolved to null
> at org.apache.el.parser.AstValue.getTarget(AstValue.java:75) [jbossweb-7.0.1.Final.jar:7.0.1.Final]
> at org.apache.el.parser.AstValue.invoke(AstValue.java:183) [jbossweb-7.0.1.Final.jar:7.0.1.Final]
> at org.apache.el.MethodExpressionImpl.invoke(MethodExpressionImpl.java:276) [jbossweb-7.0.1.Final.jar:7.0.1.Final]
> at org.jboss.weld.util.el.ForwardingMethodExpression.invoke(ForwardingMethodExpression.java:43) [weld-core-1.1.2.Final.jar:2011-07-26 15:02]
> at org.jboss.weld.el.WeldMethodExpression.invoke(WeldMethodExpression.java:56) [weld-core-1.1.2.Final.jar:2011-07-26 15:02]
> at org.richfaces.renderkit.AutocompleteRendererBase.getItems(AutocompleteRendererBase.java:105) [richfaces-components-ui-4.0.0-20110322.220419-243.jar:]
> at org.richfaces.renderkit.AutocompleteRendererBase.encodeItems(AutocompleteRendererBase.java:160) [richfaces-components-ui-4.0.0-20110322.220419-243.jar:]
> at org.richfaces.renderkit.AutocompleteRendererBase.encodeMetaComponent(AutocompleteRendererBase.java:271) [richfaces-components-ui-4.0.0-20110322.220419-243.jar:]
> {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
10 years, 8 months
[JBoss JIRA] (RF-12801) org.richfaces.resourceOptimization.enabled parameter with true value disables WebBeansELResolver to register in Websphere
by Brian Leathem (JIRA)
[ https://issues.jboss.org/browse/RF-12801?page=com.atlassian.jira.plugin.s... ]
Brian Leathem commented on RF-12801:
------------------------------------
I'm sorry [~sebcramer], but as an OSS developer I don't have access to Websphere. So unless you can reproduce it on tomcat and clearly demonstrate that it's an issue with one of the impls of CDI or JSF, and not with Websphere's handling of those libraries, then there isn't much I can do to reproduce the issue.
If you are willing to work forward with us in it, that's great. Perhaps we can take up such a discussion in the forums, and then come back to filing a RichFaces JIRA issue if an issue is in fact found.
Honestly though, trying to re-produce this with tomcat + OpenWebbeans (Try TomEE to make it easier) seems like a good way of eliminating the non-websphere issues. If it fails, then we significantly narrowed down the problem.
To get started, try debugging, starting with a breakpoint here:
https://github.com/richfaces4/core/blob/master/impl/src/main/java/org/ric...
Step through the initialisation process, and see if you can figure out why the ResourceLoadingOptimisation feature interferes with your container's ELResolver. Try this, and post your results to the user form, we can carry on the discussion there (and hopefully get more eyes/voices involved).
> org.richfaces.resourceOptimization.enabled parameter with true value disables WebBeansELResolver to register in Websphere
> -------------------------------------------------------------------------------------------------------------------------
>
> Key: RF-12801
> URL: https://issues.jboss.org/browse/RF-12801
> Project: RichFaces
> Issue Type: Bug
> Security Level: Public(Everyone can see)
> Components: resource handling
> Affects Versions: 4.3.0.Final
> Environment: Websphere 8.0.0.3 and Websphere 8.0.0.5, Windows 7, Richfaces 4.3.0.Final
> Reporter: Erdem YILMAZ
> Labels: ELResolver, optimization, resource, websphere
>
> when we use context param org.richfaces.resourceOptimization.enabled in web.xml, the CDI listener is not registered in Websphere.
> resourcesOptimization parameter disables org.apache.webbeans.el.WebBeansELResolver in Websphere. In richfaces 4.2.3.Final version, resourceOptimization parameter do not affect the CDI behaviour.
> we have disabled the resource optimization in order to work with richfaces but for the production environment, we prefer to enable it.
--
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
10 years, 8 months
[JBoss JIRA] (RF-13114) PoC: port RichFaces 4.5 UI Components to work with RichFaces 5
by Brian Leathem (JIRA)
[ https://issues.jboss.org/browse/RF-13114?page=com.atlassian.jira.plugin.s... ]
Brian Leathem commented on RF-13114:
------------------------------------
h5. Re: the reported Validator test failures after the RichFaces.ui -> RichFaces.rf4.ui
My attempts to attach a debugger to the test runs have been unsuccessful, I think because of the jsf-test container used in these tests. I tried running a real example, but the sample doesn't deploy due to other more fundamental problems (eg. DuplicateServiceException).
I propose we ignore the failing tests for now, and focus on getting the 4.5 port to a point where we can run real applications in a real container. We will then be able to debug the javascript throwing the above error, and come back to the test resolution.
> PoC: port RichFaces 4.5 UI Components to work with RichFaces 5
> --------------------------------------------------------------
>
> Key: RF-13114
> URL: https://issues.jboss.org/browse/RF-13114
> Project: RichFaces
> Issue Type: Task
> Security Level: Public(Everyone can see)
> Reporter: Lukáš Fryč
> Assignee: Michal Petrov
> Fix For: 5.0.0.Alpha2
>
> Original Estimate: 1 week
> Remaining Estimate: 1 week
>
> * open branches in own fork of
> ** richfaces5 (master)
> ** richfaces-components (4.5.x)
> ** richfaces-showcase (master)
> * modifications required
> ** change RF5 namespace -> http://richfaces.org/core
> ** change parents/bom in components 4.5 to depend on RF5 framework / build-bom
> *** remove all dependencies on 4.3.x (4.3.3-SNAPSHOT)
> ** change Java API of Components 4.5 to depend on RF5 Core API
> ** use the RF5 and RF4.5 UI Components in Showcase branch (4.5.0-SNAPSHOT)
--
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
10 years, 8 months
[JBoss JIRA] (RF-12907) render="@form" problem with a4jCommand Button / Link / @all
by Jean ANDRE (JIRA)
[ https://issues.jboss.org/browse/RF-12907?page=com.atlassian.jira.plugin.s... ]
Jean ANDRE commented on RF-12907:
---------------------------------
Not sure at all. Test have to be performed. We can imagine to solve the RF-12761 and if ITBH works, it may be mean it was the same... Another clue we found, is: When you go from a page to another page with an ajax request (eg.:a4jCommandB...), and then from the reached page, you have a back button to return to the page where you came from, you MUST, refresh exactly the same area (ids). If you use @all, @form or any other id that enclose your area, it may not work properly. Then we got the need to click twice for a button. Our expectation is, refreshing the whole page (@all), or the whole form (@form), should work at any time, whatever the area your request to refresh the new dynamic page or fragment.
> render="@form" problem with a4jCommand Button / Link / @all
> -----------------------------------------------------------
>
> Key: RF-12907
> URL: https://issues.jboss.org/browse/RF-12907
> Project: RichFaces
> Issue Type: Bug
> Security Level: Public(Everyone can see)
> Affects Versions: 4.2.3.Final, 4.3.1
> Environment: JSF Mojarra 2.1.21 or 2.1.20 - Glassfish 3.1.2 or WAS 8.0.0.x Servlet 3.0 or 2.5
> Reporter: Jean ANDRE
> Labels: waiting_on_user
> Attachments: ITBH-Maven.zip, ITBH-Maven.zip, Nested-2.1.Finale.zip, Nested-Spring-3.2.2.zip, NestedEar-CDI.zip
>
>
> Please see the report at: http://java.net/jira/browse/JAVASERVERFACES-2016
> It seems that that there is a problem with a4j button and the value of @form/render attribute.
> The symptom we got is after refreshing the panel for building a list. Click on link form the result lisk does not trigger the action.
--
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
10 years, 8 months
[JBoss JIRA] (RF-13108) rich:calendar nested a4j:ajax event not firing
by nathan dennis (JIRA)
[ https://issues.jboss.org/browse/RF-13108?page=com.atlassian.jira.plugin.s... ]
nathan dennis commented on RF-13108:
------------------------------------
having trouble remembering. I got pressed for time and had to move on quickly because of these unrealistic deadlines I'm up against right now.. but i moved the f:ajax in to production as it was function correctly. In my demo environment this morning i went back and switched out the f for a4j. and watched with developers tools. I think the call is being fired but something is up with the way the validators are processed and i have yet to figure it out. I apologize for not being more help with this.
> rich:calendar nested a4j:ajax event not firing
> ----------------------------------------------
>
> Key: RF-13108
> URL: https://issues.jboss.org/browse/RF-13108
> Project: RichFaces
> Issue Type: Bug
> Security Level: Public(Everyone can see)
> Components: component-a4j-core, component-validators
> Affects Versions: 4.3.2
> Environment: jboss 7.1.3 richfaces 4.3.2.final, chrome
> Reporter: nathan dennis
> Labels: a4j:ajax, rich:calendar, rich:message, waiting_on_user
>
> nested a4j:ajax change event isn't functioning as expected. On "change" event, the expect result is that the value is moved into the target Date field of the backing bean. When using a4j:ajax, this does not happen.
> After speaking with ppitonak he believe that the order of the ajax with relation to the validators was import. however after closer inspection, the value wasn't making back to the bean even when the event was fired even with the order reversed.
> Logically the first date should be submitted to the backing bean on change even and made available for validation in the second dates validator. works with f:ajax.. doesnt work with a4j:ajax.
> {code}
> Request URL:http://oasis.monarchnc.org:10001/oasis/screening/edit.xhtml?cid=2
> Request Method:POST
> Status Code:200 OK
> Request Headersview source
> Accept:*/*
> Accept-Charset:ISO-8859-1,utf-8;q=0.7,*;q=0.3
> Accept-Encoding:gzip,deflate,sdch
> Accept-Language:en-US,en;q=0.8
> Connection:keep-alive
> Content-Length:870
> Content-type:application/x-www-form-urlencoded;charset=UTF-8
> Cookie:JSESSIONID="gOuCLop-DL7U6D3fbNhptHmw.slave:server-three"; csfcfc=11Xfn_12Xfn; __utma=69432588.533798156.1374674467.1374674467.1374674467.1; __utmz=69432588.1374674467.1.1.utmcsr=(direct)|utmccn=(direct)|utmcmd=(none); org.monarchnc.commandcenter.location=1; org.monarchnc.commandcenter.security=NDNlZGQ3ZDU3NjIxYzI4YjM4YzZlOTM0YzQ3ZjAxYWQ_
> Faces-Request:partial/ajax
> Host:oasis.monarchnc.org:10001
> Origin:http://oasis.monarchnc.org:10001
> Referer:http://oasis.monarchnc.org:10001/oasis/screening/edit.xhtml?cid=2&id=143&dsRid=197&windowId=-9720
> User-Agent:Mozilla/5.0 (X11; Linux x86_64) AppleWebKit/537.22 (KHTML, like Gecko) Chrome/25.0.1364.172 Safari/537.22
> Query String Parametersview sourceview URL encoded
> cid:2
> Form Dataview sourceview URL encoded
> create:create
> create:medrecordnumber:
> create:patientName:Ritchard Trickle
> create:patientPhone:
> create:patientEmail:
> create:startTimeOverrideInputDate:30/7/13 04:24 PM
> create:startTimeOverrideInputCurrentDate:07/2013
> create:endTimeOverrideInputDate:01/8/13 05:58 PM
> create:endTimeOverrideInputCurrentDate:08/2013
> create:screeningBeanScreeningProviderValue:
> create:screeningBeanScreeningProviderInput:dennis, nathan
> javax.faces.ViewState:-4869776129569305131:8783263118910249789
> javax.faces.source:create:startTimeOverride
> javax.faces.partial.event:change
> javax.faces.partial.execute:create:startTimeOverride @component
> javax.faces.partial.render:@component
> javax.faces.behavior.event:change
> org.richfaces.ajax.component:create:startTimeOverride
> rfExt:null
> AJAX:EVENTS_COUNT:1
> javax.faces.partial.ajax:true
> Response Headersview source
> Cache-Control:no-cache
> Connection:close
> Content-Type:text/xml;charset=UTF-8
> Date:Thu, 01 Aug 2013 15:59:07 GMT
> Server:Apache-Coyote/1.1
> Transfer-Encoding:chunked
> X-Powered-By:JSF/2.0
> {code}
> {code:xml}
> <?xml version='1.0' encoding='UTF-8' ?>
> <!DOCTYPE html PUBLIC "-//W3C//DTD XHTML 1.0 Transitional//EN" "http://www.w3.org/TR/xhtml1/DTD/xhtml1-transitional.dtd">
> <ui:composition xmlns="http://www.w3.org/1999/xhtml"
> xmlns:h="http://java.sun.com/jsf/html"
> xmlns:f="http://java.sun.com/jsf/core"
> xmlns:ui="http://java.sun.com/jsf/facelets"
> xmlns:c="http://java.sun.com/jsp/jstl/core"
> xmlns:a4j="http://richfaces.org/a4j"
> xmlns:rich="http://richfaces.org/rich"
> template="/resources/scaffold/pageTemplate.xhtml">
> <f:metadata>
> <f:viewParam name="id" value="#{screeningBean.id}"/>
> </f:metadata>
> <ui:define name="main">
> <h:form id="create">
>
> <h:panelGrid columnClasses="label,component,required" columns="3">
> <h:outputLabel for="startTimeOverride" value="Start Time Override:"/>
> <rich:calendar value="#{screeningBean.screening.beginTime}" id="startTimeOverride"
> popup="true" datePattern="dd/M/yy hh:mm a" required="true"
> showApplyButton="true" >
> <f:validateRequired />
> <a4j:ajax event="change" bypassUpdates="#{true}"/>
> </rich:calendar>
> <rich:message for="startTimeOverride" ajaxRendered="true" />
> <h:outputLabel for="endTimeOverride" value="End Time Override:" />
> <rich:calendar value="#{screeningBean.screening.endTime}" id="endTimeOverride"
> popup="true" datePattern="dd/M/yy hh:mm a"
> showApplyButton="true" >
> <f:validateRequired />
> <f:validator validatorId="dateRangeValidator" />
> <rich:validator />
> <a4j:ajax event="change" bypassUpdates="#{true}"/>
> </rich:calendar>
> <rich:message for="endTimeOverride" ajaxRendered="true" />
> </h:panelGrid>
> <div class="buttons">
> <a4j:commandButton value="Complete"
> action="#{screeningBean.updateScreening(2)}"
> execute="@form"
> onclick="this.disabled=true; var that = this; setTimeout(function() that.disabled=false;},500);"
> styleClass="btn btn-primary btn-primary-a4j" />
> </div>
> </h:form>
> </ui:define>
> </ui:composition>
> {code}
> {code:title=DateRangeValidator.java}
> /**************************************************************
> * Copyright (c) 2012 - 2013, Monarch, All rights reserved.
> *
> * @author Nathan Dennis
> *
> */
> package org.monarchnc.view.validators;
> import java.text.DateFormat;
> import java.text.SimpleDateFormat;
> import java.util.Date;
> import javax.faces.application.FacesMessage;
> import javax.faces.component.UIComponent;
> import javax.faces.component.UIInput;
> import javax.faces.context.FacesContext;
> import javax.faces.validator.FacesValidator;
> import javax.faces.validator.Validator;
> import javax.faces.validator.ValidatorException;
> import javax.persistence.EntityManager;
> import org.apache.deltaspike.core.api.provider.BeanProvider;
> import org.monarchnc.view.ScreeningBean;
> // TODO: Auto-generated Javadoc
> /**
> * The Class DateRangeValidator.
> */
> @FacesValidator("dateRangeValidator")
> public class DateRangeValidator implements Validator {
>
>
> /* (non-Javadoc)
> * @see javax.faces.validator.Validator#validate(javax.faces.context.FacesContext, javax.faces.component.UIComponent, java.lang.Object)f
> */
> public void validate(final FacesContext ctx, final UIComponent component, final Object value) throws ValidatorException {
>
> ScreeningBean screeningBean = BeanProvider.getContextualReference(screeningBean.class, false);
>
> Date date =(Date) value;
> if(screeningBean.getScreening().getBeginTime() != null && date != null)
> if(!date.after(screeningBean.getScreening().getBeginTime())){
> throw new ValidatorException(new FacesMessage(FacesMessage.SEVERITY_ERROR,"End Date must be after Start Date!!.\n","End Date must be after Start Date!!\n"));
>
> }
>
>
> }
> }
> {code}
> {code:title=ScreeningBean.java}
> @Named
> @Transactional
> @ConversationScoped
> public class ScreeningBean implements Serializable{
> Screening screening = new Screening();
> public Class<? extends ViewConfig> claim(){
> if (this.conversation.isTransient())
> {
> this.conversation.begin();
> }...
> }
> public Screening getScreening() {
> return screening;
> }
> public void setScreening(Screening screening) {
> this.screening = screening;
> }
> }
> {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
10 years, 8 months
[JBoss JIRA] (RF-12801) org.richfaces.resourceOptimization.enabled parameter with true value disables WebBeansELResolver to register in Websphere
by Sebastian Cramer (JIRA)
[ https://issues.jboss.org/browse/RF-12801?page=com.atlassian.jira.plugin.s... ]
Sebastian Cramer commented on RF-12801:
---------------------------------------
[~bleathem] Reproducing an error on a different Container with a different application. That is going to be quite a masterpiece. :-)
I also dont agree with "closed cannot reproduce" - but thats besides the point.
Now for a solution:
Is there no way that I can try to debug this problem with my container here? That's all I am asking for - some guidance. Where can I start looking. I am totally lost in the behemoth "richfaces sources".
> org.richfaces.resourceOptimization.enabled parameter with true value disables WebBeansELResolver to register in Websphere
> -------------------------------------------------------------------------------------------------------------------------
>
> Key: RF-12801
> URL: https://issues.jboss.org/browse/RF-12801
> Project: RichFaces
> Issue Type: Bug
> Security Level: Public(Everyone can see)
> Components: resource handling
> Affects Versions: 4.3.0.Final
> Environment: Websphere 8.0.0.3 and Websphere 8.0.0.5, Windows 7, Richfaces 4.3.0.Final
> Reporter: Erdem YILMAZ
> Labels: ELResolver, optimization, resource, websphere
>
> when we use context param org.richfaces.resourceOptimization.enabled in web.xml, the CDI listener is not registered in Websphere.
> resourcesOptimization parameter disables org.apache.webbeans.el.WebBeansELResolver in Websphere. In richfaces 4.2.3.Final version, resourceOptimization parameter do not affect the CDI behaviour.
> we have disabled the resource optimization in order to work with richfaces but for the production environment, we prefer to enable it.
--
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
10 years, 8 months
[JBoss JIRA] (RF-11469) autocomplete method does not resolve bean if ui:included
by Valiantsin Shukaila (JIRA)
[ https://issues.jboss.org/browse/RF-11469?page=com.atlassian.jira.plugin.s... ]
Valiantsin Shukaila updated RF-11469:
-------------------------------------
Attachment: RF-11469.zip
Attaching eclipse maven project with complete example for reproducing the issue.
> autocomplete method does not resolve bean if ui:included
> --------------------------------------------------------
>
> Key: RF-11469
> URL: https://issues.jboss.org/browse/RF-11469
> Project: RichFaces
> Issue Type: Bug
> Security Level: Public(Everyone can see)
> Components: component-input
> Affects Versions: 4.0.0.Final
> Reporter: u j
> Assignee: Lukáš Fryč
> Priority: Minor
> Labels: waiting_on_user
> Attachments: RF-11469.zip
>
> Original Estimate: 45 minutes
> Remaining Estimate: 45 minutes
>
> A bean parameter in the autocomplete method is not resolved if the rich:autocomplete is part of a ui:include.
> {code}
> <ui:include src="/searchlocation.xhtml">
> <ui:param name="bean" value="#{searchBean}" />
> </ui:include>
> {code}
> searchlocation.xhtml contains:
> {code}
> <rich:autocomplete id="cityName" mode="ajax" value="#{bean.cityName}" autocompleteMethod="#{bean.suggestCities}" />
> {code}
> The value binding works, but the binding in the autocompleteMethod gives:
> {code}
> 15:26:15,809 SEVERE [org.richfaces.log.Renderkit] (ajp-127.0.0.1-127.0.0.1-8009-1) Target Unreachable, identifier 'bean' resolved to null: javax.el.PropertyNotFoundException: Target Unreachable, identifier 'bean' resolved to null
> at org.apache.el.parser.AstValue.getTarget(AstValue.java:75) [jbossweb-7.0.1.Final.jar:7.0.1.Final]
> at org.apache.el.parser.AstValue.invoke(AstValue.java:183) [jbossweb-7.0.1.Final.jar:7.0.1.Final]
> at org.apache.el.MethodExpressionImpl.invoke(MethodExpressionImpl.java:276) [jbossweb-7.0.1.Final.jar:7.0.1.Final]
> at org.jboss.weld.util.el.ForwardingMethodExpression.invoke(ForwardingMethodExpression.java:43) [weld-core-1.1.2.Final.jar:2011-07-26 15:02]
> at org.jboss.weld.el.WeldMethodExpression.invoke(WeldMethodExpression.java:56) [weld-core-1.1.2.Final.jar:2011-07-26 15:02]
> at org.richfaces.renderkit.AutocompleteRendererBase.getItems(AutocompleteRendererBase.java:105) [richfaces-components-ui-4.0.0-20110322.220419-243.jar:]
> at org.richfaces.renderkit.AutocompleteRendererBase.encodeItems(AutocompleteRendererBase.java:160) [richfaces-components-ui-4.0.0-20110322.220419-243.jar:]
> at org.richfaces.renderkit.AutocompleteRendererBase.encodeMetaComponent(AutocompleteRendererBase.java:271) [richfaces-components-ui-4.0.0-20110322.220419-243.jar:]
> {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
10 years, 8 months