May 2010 - richfaces-issues - Jboss List Archives

[JBoss JIRA] Created: (RF-6958) RichFaces and Trinidad compatibility issue on Weblogic 10.1 (and Higher)

by Maxim Pavlov (JIRA)

RichFaces and Trinidad compatibility issue on Weblogic 10.1 (and Higher) ------------------------------------------------------------------------ Key: RF-6958 URL: https://jira.jboss.org/jira/browse/RF-6958 Project: RichFaces Issue Type: Bug Components: core Affects Versions: 3.3.0 Environment: Weblogic 10.1 (Same on 10.3), JSF 1.2 (RI), RichFaces 3.3.0, Trinidad 1.2.11 Reporter: Maxim Pavlov Trinidad PPR response can not be parsed in browser if a4j filter is enabled. Ajax4jsf builds in response and modyfies the html content. As a result trinidad can not parse the response on the client side. This code below in org.ajax4jsf.webapp.BaseFilter.handleRequest solved the issue but I'm more than sure that it is not the best solution anyway. protected void handleRequest(HttpServletRequest request, HttpServletResponse response, FilterChain chain) throws IOException, ServletException { final String TRININDAD_PPR_FLAG_PARTIAL = "partial"; final String AJAXREQUEST_FLAG = "AJAXREQUEST"; boolean isTrinidadRequest = request.getParameterMap().containsKey(TRININDAD_PPR_FLAG_PARTIAL) && !request.getParameterMap().containsKey(AJAXREQUEST_FLAG); if (!isTrinidadRequest) { if (log.isDebugEnabled()) { log.debug(Messages .getMessage(Messages.FILTER_XML_OUTPUT)); } // Execute the rest of the filter chain, including the // JSP xmlFilter.doXmlFilter(chain, request, response); } else { // normal request, execute chain ... if (log.isDebugEnabled()) { log.debug(Messages .getMessage(Messages.FILTER_NO_XML_CHAIN)); } chain.doFilter(request, response); } } -- This message is automatically generated by JIRA. - If you think it was sent incorrectly contact one of the administrators: https://jira.jboss.org/jira/secure/Administrators.jspa - For more information on JIRA, see: http://www.atlassian.com/software/jira

14 years, 6 months

3
3
0 / 0

[JBoss JIRA] Created: (RF-6902) slow deployment of richfaces-ui

by David Schlotfeldt (JIRA)

slow deployment of richfaces-ui ------------------------------- Key: RF-6902 URL: https://jira.jboss.org/jira/browse/RF-6902 Project: RichFaces Issue Type: Feature Request Affects Versions: 3.3.0 Reporter: David Schlotfeldt ResourceBuilderImpl loads resources-config.xml files. Loading jar:file:/...../richfaces-ui-3.3.0.GA.jar!/META-INF/resources-config.xml takes 2-3 seconds. This is a large issue when you have a number of sites using jsf. We have about 50 or so.. so this adds 1-2 minutes to the start up of jboss. Can this be optimized in some way? Lazy-initialize in some way? (The config contains a LARGE number of resources. Im not sure what the config loading is doing but I bet we never use more then a handful of them.) Thanks! David -- This message is automatically generated by JIRA. - If you think it was sent incorrectly contact one of the administrators: https://jira.jboss.org/jira/secure/Administrators.jspa - For more information on JIRA, see: http://www.atlassian.com/software/jira

14 years, 6 months

3
3
0 / 0

[JBoss JIRA] Created: (RF-5598) a4j:push is not portlet session aware

by Dirk Pitt (JIRA)

a4j:push is not portlet session aware ------------------------------------- Key: RF-5598 URL: https://jira.jboss.org/jira/browse/RF-5598 Project: RichFaces Issue Type: Bug Components: portal Affects Versions: 3.3.0 Environment: Richfaces 3.3.0.CR2, JBoss Portletbridge 1.0.0.B5, JBoss Portal 2.6.4 Reporter: Dirk Pitt Hallo, I have funny problem with a4j:pushBean... We have a web application, which runs perfectly in test environment with single web client. But if for the same page in the web application another browser client is opened, second browser start receiving the events intended for the first browser... So my first impression is that push functionality make no distinction about from which session is called... So I surf little bit in the source code and here what I found.... In org.ajax4jsf.webapp.BaseFilter an instance of PushEventsCounter is obtained with the following call PushEventsCounter listener = eventsManager .getListener(ajaxPushHeader); which my debuging shows ajaxPushHeader contains no session specific information. At this point I have to say I am using the JBoss Portal and JBoss Portlet Bridge. I made some more debuging and I found this.... In org.ajax4jsf.component.UIPush in method getListenerId method only HttpSession case taking into count.... Object session = context.getExternalContext().getSession(false); StringBuffer id = new StringBuffer(); if(null != session && session instanceof HttpSession){ HttpSession httpSession = (HttpSession) session; id.append(httpSession.getId()); } id.append(context.getViewRoot().getViewId()); id.append(NamingContainer.SEPARATOR_CHAR); id.append(getClientId(context)); return id.toString(); But portal delivers PortletSession object so the SessionId is not there at that is causing the mentioned problem... Now this problem is quite critical for our project and I can actually deliver code solution to be commited jboss source tree also but the question is how to solve this without putting portal dependencies to Richfaces classes... Or can we solve this PortletBridge? -- This message is automatically generated by JIRA. - If you think it was sent incorrectly contact one of the administrators: https://jira.jboss.org/jira/secure/Administrators.jspa - For more information on JIRA, see: http://www.atlassian.com/software/jira

14 years, 6 months

4
8
0 / 0

[JBoss JIRA] Created: (RF-4398) Form: ajax form doesn't handle ajaxSingle in the right way

by Nick Belaevski (JIRA)

Form: ajax form doesn't handle ajaxSingle in the right way ---------------------------------------------------------- Key: RF-4398 URL: https://jira.jboss.org/jira/browse/RF-4398 Project: RichFaces Issue Type: Bug Affects Versions: 3.2.2 Reporter: Nick Belaevski Assignee: Alexander Smirnov Fix For: Future <a4j:form ajaxSubmit="true" ajaxSingle="true" id="a4jform"> Ajax single <h:inputText /> <h:commandButton actionListener="#{capitalsBean.action}" value="Button" id="button" /> </a4j:form> Pressing button submits the following parameters: AJAXREQUEST _viewRoot a4jform a4jform a4jform a4jform a4jform:button Button a4jform:j_id236 22 ajaxSingle a4jform autoScroll javax.faces.ViewState j_id2 ajaxSingle should be a4jform:button, duplicate parameters should not be submitted -- This message is automatically generated by JIRA. - If you think it was sent incorrectly contact one of the administrators: https://jira.jboss.org/jira/secure/Administrators.jspa - For more information on JIRA, see: http://www.atlassian.com/software/jira

14 years, 6 months

2
3
0 / 0

[JBoss JIRA] Created: (RF-4165) Support Plug n Skin feature in the portlets

by Alexander Smirnov (JIRA)

Support Plug n Skin feature in the portlets ------------------------------------------- Key: RF-4165 URL: https://jira.jboss.org/jira/browse/RF-4165 Project: RichFaces Issue Type: Feature Request Affects Versions: 3.2.1 Environment: Jboss Portal, portletbridge. Reporter: Alexander Smirnov Assignee: Alexander Smirnov Fix For: 3.2.2 When attempting to use a skin in JBoss Portal created using the Plug n Skin Tool for Richfaces components, the <skin-name>.skin.properties file is not referencing the <skin-name>.xcss file located at META-INFskins. Instead, the base skin properties are being used to render the Richfaces components. -- This message is automatically generated by JIRA. - If you think it was sent incorrectly contact one of the administrators: https://jira.jboss.org/jira/secure/Administrators.jspa - For more information on JIRA, see: http://www.atlassian.com/software/jira

14 years, 6 months

2
3
0 / 0

[JBoss JIRA] Created: (RF-4084) Auto tests development: portlets

by Nick Belaevski (JIRA)

Auto tests development: portlets -------------------------------- Key: RF-4084 URL: https://jira.jboss.org/jira/browse/RF-4084 Project: RichFaces Issue Type: Task Components: planning Reporter: Nick Belaevski Assignee: Alexander Smirnov -- This message is automatically generated by JIRA. - If you think it was sent incorrectly contact one of the administrators: https://jira.jboss.org/jira/secure/Administrators.jspa - For more information on JIRA, see: http://www.atlassian.com/software/jira

14 years, 6 months

2
4
0 / 0

[JBoss JIRA] Created: (RF-3849) rich:simpleTogglePanel bodyClass and headerClass attributes do not work in JBoss Portal environment.

by Tareq Nabeel (JIRA)

rich:simpleTogglePanel bodyClass and headerClass attributes do not work in JBoss Portal environment. ---------------------------------------------------------------------------------------------------- Key: RF-3849 URL: http://jira.jboss.com/jira/browse/RF-3849 Project: RichFaces Issue Type: Bug Components: portal Affects Versions: 3.2.1 Environment: RichFaces 3.2.1, JBoss Portal 2.6.5.SP1 Reporter: Tareq Nabeel CSS classes specified in bodyClass and headerClass attributes of <rich:simpleTogglePanel> do not override default skin settings in JBoss Portal environment. They do override correctly in JBoss 4.2.2. -- This message is automatically generated by JIRA. - If you think it was sent incorrectly contact one of the administrators: http://jira.jboss.com/jira/secure/Administrators.jspa - For more information on JIRA, see: http://www.atlassian.com/software/jira

14 years, 6 months

3
4
0 / 0

[JBoss JIRA] Created: (RF-3729) State manager tags

by Nick Belaevski (JIRA)

State manager tags ------------------ Key: RF-3729 URL: http://jira.jboss.com/jira/browse/RF-3729 Project: RichFaces Issue Type: Feature Request Components: planning Affects Versions: 3.3.0 Reporter: Nick Belaevski Assigned To: Alexander Smirnov Fix For: 3.3.0 -- This message is automatically generated by JIRA. - If you think it was sent incorrectly contact one of the administrators: http://jira.jboss.com/jira/secure/Administrators.jspa - For more information on JIRA, see: http://www.atlassian.com/software/jira

14 years, 6 months

2
6
0 / 0

[JBoss JIRA] Created: (RF-3273) Ajax response should not send <head> tag

by Dan Allen (JIRA)

Ajax response should not send <head> tag ---------------------------------------- Key: RF-3273 URL: http://jira.jboss.com/jira/browse/RF-3273 Project: RichFaces Issue Type: Bug Affects Versions: 3.2.0 Reporter: Dan Allen There is an expectation that Ajax responses are reasonably small. However, RichFaces Ajax responses are unreasonably large because the BaseXMLFilter is mistakingly sending the entire <head> tag regardless of whether the response type is Ajax or not. The <head> tag contains many <script> and <link> tags that bloat the response. The BaseXMLFilter should only be sending the <head> tag on a normal response. Now you might think, "What if the region to be rendered has new components (that were not previously rendered) for which styles and scripts are necessary for proper behavior?" Well, RichFaces is already smart and incorporates these styles and scripts into the initial response even if the associated components are not rendered. So there is absolutely *no* reason to have them sent in the Ajax response. -- This message is automatically generated by JIRA. - If you think it was sent incorrectly contact one of the administrators: http://jira.jboss.com/jira/secure/Administrators.jspa - For more information on JIRA, see: http://www.atlassian.com/software/jira

14 years, 6 months

3
13
0 / 0

[JBoss JIRA] Created: (RF-2505) wizard using a4j:include doesn't work in ie7 after you hit ie7 back button

by Pavel Savara (JIRA)

wizard using a4j:include doesn't work in ie7 after you hit ie7 back button -------------------------------------------------------------------------- Key: RF-2505 URL: http://jira.jboss.com/jira/browse/RF-2505 Project: RichFaces Issue Type: Bug Affects Versions: 3.1.4, 3.1.3 Environment: Windows XP, Internet Explorer7 Reporter: Pavel Savara Steps which leads to expose the bug. 1. Go to http://livedemo.exadel.com/richfaces-demo/richfaces/include.jsf?c=include 2. fill the a4j:include wizard and click next 3. Click on Tag information tab 4. Hit Internet Explorer back button you should be back on the main page 5. <a4j:include> wizard is on first page again and if you click on next nothing happens!. This is tested in Internet Explorer 7. In Firefox everything works fine and after step 4. you see again second page of the wizard. I have the same problem in my own pages. -- This message is automatically generated by JIRA. - If you think it was sent incorrectly contact one of the administrators: http://jira.jboss.com/jira/secure/Administrators.jspa - For more information on JIRA, see: http://www.atlassian.com/software/jira

14 years, 6 months

4
11
0 / 0

2024

2023

2022

2021

2020

2019

2018

2017

2016

2015

2014

2013

2012

2011

2010

2009

2008

2007

richfaces-issues May 2010