[JBoss JIRA] (RF-12948) rich:autocomplete problems with nested rich:placeholder
by nathan dennis (JIRA)
nathan dennis created RF-12948:
----------------------------------
Summary: rich:autocomplete problems with nested rich:placeholder
Key: RF-12948
URL: https://issues.jboss.org/browse/RF-12948
Project: RichFaces
Issue Type: Feature Request
Security Level: Public (Everyone can see)
Affects Versions: 4.3.1
Environment: centos 6.x firefox, chrome ...
Reporter: nathan dennis
placeholder works. However, autocomplete selection list is displaying with undocumented features. Rows are there.. line height is wrong... and there is no text visible.
recreate by simply adding a placeholder to one of the autocompletes in the showcase app.
--
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
11 years
[JBoss JIRA] (RF-12943) ExtendedDataTable: filterType custom and clearing of filter input doesnt work correctly
by Brian Leathem (JIRA)
[ https://issues.jboss.org/browse/RF-12943?page=com.atlassian.jira.plugin.s... ]
Brian Leathem updated RF-12943:
-------------------------------
Labels: testcase_provided (was: )
> ExtendedDataTable: filterType custom and clearing of filter input doesnt work correctly
> ---------------------------------------------------------------------------------------
>
> Key: RF-12943
> URL: https://issues.jboss.org/browse/RF-12943
> Project: RichFaces
> Issue Type: Bug
> Security Level: Public(Everyone can see)
> Components: component-tables
> Affects Versions: 4.3.1
> Environment: Tomcat 7, Mojarra 2.1.21
> Reporter: dako ak
> Labels: testcase_provided
> Fix For: 5-Tracking
>
> Attachments: JSF2-RichFaces-Test.zip
>
>
> According to my appended test project:
> I have a simple extendedDataTable with one column (firstName) with a filter input component within the header. This is the default filter input created by the extendedDataTable. The second column (city) has a filterType="custom" and an inputText componenent within the header. The filterType attribute with value "custom" is ignored because the default input text is rendered too.
> The second problem with the input filter is that I can't clear this filter input text components by a a4j:commandButton. The table is correct filtered but the filter input text fields are not cleared.
--
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
11 years
[JBoss JIRA] (RF-11000) Hit miss for class loader cost performance problem in Richfaces 4.1.0.
by Brian Leathem (JIRA)
[ https://issues.jboss.org/browse/RF-11000?page=com.atlassian.jira.plugin.s... ]
Brian Leathem updated RF-11000:
-------------------------------
Fix Version/s: 5.0.0.Alpha2
(was: 5-Tracking)
> Hit miss for class loader cost performance problem in Richfaces 4.1.0.
> ----------------------------------------------------------------------
>
> Key: RF-11000
> URL: https://issues.jboss.org/browse/RF-11000
> Project: RichFaces
> Issue Type: Bug
> Security Level: Public(Everyone can see)
> Components: core
> Affects Versions: 4.1.0.Milestone1
> Environment: Linux, Java 6
> Reporter: Pawel J.
> Assignee: Brian Leathem
> Labels: patch_proposed
> Fix For: 5.0.0.Alpha2
>
> Attachments: ResourceFactoryImpl-patch.txt
>
> Original Estimate: 1 hour
> Remaining Estimate: 1 hour
>
> There are scenarios when resources are retrieved during no partial
> request processing:
> # JSF html renderer (such as ScriptRenderer from faces) require to
> know resources names to include them to html/head,
> # Resources content request.
> We have two types of resources: dynamic and static. Predefined dynamic
> resources (such as StateHolderResource) are read using class loader as
> they are java classes. Static resources are kept in resources folder
> as part of richfaces release jars (jquery.js, richfaces.js, etc).
> There is a special case with compiled css that is consider as dynamic
> resources but is not important in our case.
> The problem appears when we try to load static resources using dynamic
> loader. This make unnecessary lookup in java class loader space which
> cost time and of course we miss the call as static resources not
> exists there.
> Statistics that shows class loader hits for every richfaces/ajax4jsf no partial request that will be eliminated after patch:
> {code}
> Resource::jquery.js ::loading::timens:: 558000 ns::timems::0.558 ms::all::1.561496 sec
> Resource::richfaces.js ::loading::timens:: 490000 ns::timems::0.490 ms::all::1.561986 sec
> Resource::richfaces-base-component.js::loading::timens:: 593000 ns::timems::0.593 ms::all::1.563672 sec
> Resource::richfaces-queue.js ::loading::timens:: 672000 ns::timems::0.672 ms::all::1.564350 sec
> Resource::richfaces-event.js ::loading::timens::3292000 ns::timems::3.292 ms::all::1.569386 sec
> {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
11 years
[JBoss JIRA] (RF-12943) ExtendedDataTable: filterType custom and clearing of filter input doesnt work correctly
by Brian Leathem (JIRA)
[ https://issues.jboss.org/browse/RF-12943?page=com.atlassian.jira.plugin.s... ]
Brian Leathem updated RF-12943:
-------------------------------
Fix Version/s: 5-Tracking
> ExtendedDataTable: filterType custom and clearing of filter input doesnt work correctly
> ---------------------------------------------------------------------------------------
>
> Key: RF-12943
> URL: https://issues.jboss.org/browse/RF-12943
> Project: RichFaces
> Issue Type: Bug
> Security Level: Public(Everyone can see)
> Components: component-tables
> Affects Versions: 4.3.1
> Environment: Tomcat 7, Mojarra 2.1.21
> Reporter: dako ak
> Fix For: 5-Tracking
>
> Attachments: JSF2-RichFaces-Test.zip
>
>
> According to my appended test project:
> I have a simple extendedDataTable with one column (firstName) with a filter input component within the header. This is the default filter input created by the extendedDataTable. The second column (city) has a filterType="custom" and an inputText componenent within the header. The filterType attribute with value "custom" is ignored because the default input text is rendered too.
> The second problem with the input filter is that I can't clear this filter input text components by a a4j:commandButton. The table is correct filtered but the filter input text fields are not cleared.
--
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
11 years
[JBoss JIRA] (RF-11000) Hit miss for class loader cost performance problem in Richfaces 4.1.0.
by Brian Leathem (JIRA)
[ https://issues.jboss.org/browse/RF-11000?page=com.atlassian.jira.plugin.s... ]
Brian Leathem updated RF-11000:
-------------------------------
Fix Version/s: 5-Tracking
(was: 5-Future)
> Hit miss for class loader cost performance problem in Richfaces 4.1.0.
> ----------------------------------------------------------------------
>
> Key: RF-11000
> URL: https://issues.jboss.org/browse/RF-11000
> Project: RichFaces
> Issue Type: Bug
> Security Level: Public(Everyone can see)
> Components: core
> Affects Versions: 4.1.0.Milestone1
> Environment: Linux, Java 6
> Reporter: Pawel J.
> Assignee: Brian Leathem
> Labels: patch_proposed
> Fix For: 5-Tracking
>
> Attachments: ResourceFactoryImpl-patch.txt
>
> Original Estimate: 1 hour
> Remaining Estimate: 1 hour
>
> There are scenarios when resources are retrieved during no partial
> request processing:
> # JSF html renderer (such as ScriptRenderer from faces) require to
> know resources names to include them to html/head,
> # Resources content request.
> We have two types of resources: dynamic and static. Predefined dynamic
> resources (such as StateHolderResource) are read using class loader as
> they are java classes. Static resources are kept in resources folder
> as part of richfaces release jars (jquery.js, richfaces.js, etc).
> There is a special case with compiled css that is consider as dynamic
> resources but is not important in our case.
> The problem appears when we try to load static resources using dynamic
> loader. This make unnecessary lookup in java class loader space which
> cost time and of course we miss the call as static resources not
> exists there.
> Statistics that shows class loader hits for every richfaces/ajax4jsf no partial request that will be eliminated after patch:
> {code}
> Resource::jquery.js ::loading::timens:: 558000 ns::timems::0.558 ms::all::1.561496 sec
> Resource::richfaces.js ::loading::timens:: 490000 ns::timems::0.490 ms::all::1.561986 sec
> Resource::richfaces-base-component.js::loading::timens:: 593000 ns::timems::0.593 ms::all::1.563672 sec
> Resource::richfaces-queue.js ::loading::timens:: 672000 ns::timems::0.672 ms::all::1.564350 sec
> Resource::richfaces-event.js ::loading::timens::3292000 ns::timems::3.292 ms::all::1.569386 sec
> {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
11 years
[JBoss JIRA] (RF-8543) Calendar position is incorrect inside scrollable element
by Monica longhurst (JIRA)
[ https://issues.jboss.org/browse/RF-8543?page=com.atlassian.jira.plugin.sy... ]
Monica longhurst commented on RF-8543:
--------------------------------------
Good day
I was just wondering if there is perhaps a work around for the problem?
> Calendar position is incorrect inside scrollable element
> --------------------------------------------------------
>
> Key: RF-8543
> URL: https://issues.jboss.org/browse/RF-8543
> Project: RichFaces
> Issue Type: Bug
> Security Level: Public(Everyone can see)
> Components: component-input
> Affects Versions: 3.3.2.SR1
> Reporter: Andrei Markavtsov
> Fix For: 3.Future
>
> Attachments: calendardirection.JPG, screenshot-1.jpg
>
>
> <ui:composition>
> <div style="height: 200px; overflow-y: auto; width: 700px">
> <div style="height: 500px">
> <br/><br/><br/><br/><br/><br/><br/><br/><br/><br/><br/><br/><br/>
> <rich:calendar direction="auto" jointPoint="auto" />
> </div>
> </div>
> </ui:composition>
--
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
11 years
[JBoss JIRA] (RF-12947) Tree: Could not serialize state: org.richfaces.model.SwingTreeNodeDataModelImpl with MyFaces
by Pavol Pitonak (JIRA)
Pavol Pitonak created RF-12947:
----------------------------------
Summary: Tree: Could not serialize state: org.richfaces.model.SwingTreeNodeDataModelImpl with MyFaces
Key: RF-12947
URL: https://issues.jboss.org/browse/RF-12947
Project: RichFaces
Issue Type: Bug
Security Level: Public (Everyone can see)
Affects Versions: 4.3.1, 4.3.2
Reporter: Pavol Pitonak
# git clone git://github.com/richfaces/qa.git
# git checkout 4.3.x
# mvn clean verify -P tomee-remote-1-5 -Dtest=TestRowKeyConverter -Dmethod=testToggle
result:
* one of three tests fail on TomEE (MyFaces) with this error:
{quote}
Apr 26, 2013 1:34:03 PM org.apache.myfaces.application.viewstate.ServerSideStateCacheImpl serializeView
SEVERE: Exiting serializeView - Could not serialize state: org.richfaces.model.SwingTreeNodeDataModelImpl
java.io.NotSerializableException: org.richfaces.model.SwingTreeNodeDataModelImpl
at java.io.ObjectOutputStream.writeObject0(ObjectOutputStream.java:1180)
at java.io.ObjectOutputStream.defaultWriteFields(ObjectOutputStream.java:1528)
at java.io.ObjectOutputStream.writeSerialData(ObjectOutputStream.java:1493)
at java.io.ObjectOutputStream.writeOrdinaryObject(ObjectOutputStream.java:1416)
at java.io.ObjectOutputStream.writeObject0(ObjectOutputStream.java:1174)
at java.io.ObjectOutputStream.writeObject(ObjectOutputStream.java:346)
at java.util.HashMap.writeObject(HashMap.java:1014)
at sun.reflect.GeneratedMethodAccessor173.invoke(Unknown Source)
at sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:43)
at java.lang.reflect.Method.invoke(Method.java:601)
at java.io.ObjectStreamClass.invokeWriteObject(ObjectStreamClass.java:975)
at java.io.ObjectOutputStream.writeSerialData(ObjectOutputStream.java:1480)
at java.io.ObjectOutputStream.writeOrdinaryObject(ObjectOutputStream.java:1416)
at java.io.ObjectOutputStream.writeObject0(ObjectOutputStream.java:1174)
at java.io.ObjectOutputStream.writeArray(ObjectOutputStream.java:1362)
at java.io.ObjectOutputStream.writeObject0(ObjectOutputStream.java:1170)
at java.io.ObjectOutputStream.writeObject(ObjectOutputStream.java:346)
at java.util.HashMap.writeObject(HashMap.java:1014)
at sun.reflect.GeneratedMethodAccessor173.invoke(Unknown Source)
at sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:43)
at java.lang.reflect.Method.invoke(Method.java:601)
at java.io.ObjectStreamClass.invokeWriteObject(ObjectStreamClass.java:975)
at java.io.ObjectOutputStream.writeSerialData(ObjectOutputStream.java:1480)
at java.io.ObjectOutputStream.writeOrdinaryObject(ObjectOutputStream.java:1416)
at java.io.ObjectOutputStream.writeObject0(ObjectOutputStream.java:1174)
at java.io.ObjectOutputStream.writeArray(ObjectOutputStream.java:1362)
at java.io.ObjectOutputStream.writeObject0(ObjectOutputStream.java:1170)
at java.io.ObjectOutputStream.writeObject(ObjectOutputStream.java:346)
at org.apache.myfaces.application.viewstate.ServerSideStateCacheImpl.serializeView(ServerSideStateCacheImpl.java:411)
at org.apache.myfaces.application.viewstate.ServerSideStateCacheImpl.saveSerializedViewInServletSession(ServerSideStateCacheImpl.java:300)
at org.apache.myfaces.application.viewstate.ServerSideStateCacheImpl.saveSerializedView(ServerSideStateCacheImpl.java:578)
at org.apache.myfaces.renderkit.html.HtmlResponseStateManager.saveState(HtmlResponseStateManager.java:146)
at org.apache.myfaces.application.StateManagerImpl.saveView(StateManagerImpl.java:194)
at org.apache.myfaces.view.facelets.FaceletViewDeclarationLanguage.renderView(FaceletViewDeclarationLanguage.java:2052)
at org.apache.myfaces.application.ViewHandlerImpl.renderView(ViewHandlerImpl.java:285)
at javax.faces.application.ViewHandlerWrapper.renderView(ViewHandlerWrapper.java:59)
at javax.faces.application.ViewHandlerWrapper.renderView(ViewHandlerWrapper.java:59)
at org.apache.myfaces.lifecycle.RenderResponseExecutor.execute(RenderResponseExecutor.java:116)
at org.apache.myfaces.lifecycle.LifecycleImpl.render(LifecycleImpl.java:241)
at javax.faces.webapp.FacesServlet.service(FacesServlet.java:199)
at org.apache.catalina.core.ApplicationFilterChain.internalDoFilter(ApplicationFilterChain.java:305)
at org.apache.catalina.core.ApplicationFilterChain.doFilter(ApplicationFilterChain.java:210)
at org.richfaces.tests.metamer.TestIdentityFilter.doFilter(TestIdentityFilter.java:93)
at org.apache.catalina.core.ApplicationFilterChain.internalDoFilter(ApplicationFilterChain.java:243)
at org.apache.catalina.core.ApplicationFilterChain.doFilter(ApplicationFilterChain.java:210)
at org.apache.catalina.core.StandardWrapperValve.invoke(StandardWrapperValve.java:222)
at org.apache.catalina.core.StandardContextValve.invoke(StandardContextValve.java:123)
at org.apache.tomee.catalina.OpenEJBValve.invoke(OpenEJBValve.java:45)
at org.apache.catalina.authenticator.AuthenticatorBase.invoke(AuthenticatorBase.java:472)
at org.apache.catalina.core.StandardHostValve.invoke(StandardHostValve.java:171)
at org.apache.catalina.valves.ErrorReportValve.invoke(ErrorReportValve.java:99)
at org.apache.catalina.valves.AccessLogValve.invoke(AccessLogValve.java:936)
at org.apache.catalina.core.StandardEngineValve.invoke(StandardEngineValve.java:118)
at org.apache.catalina.connector.CoyoteAdapter.service(CoyoteAdapter.java:407)
at org.apache.coyote.http11.AbstractHttp11Processor.process(AbstractHttp11Processor.java:1004)
at org.apache.coyote.AbstractProtocol$AbstractConnectionHandler.process(AbstractProtocol.java:589)
at org.apache.tomcat.util.net.JIoEndpoint$SocketProcessor.run(JIoEndpoint.java:312)
at java.util.concurrent.ThreadPoolExecutor.runWorker(ThreadPoolExecutor.java:1110)
at java.util.concurrent.ThreadPoolExecutor$Worker.run(ThreadPoolExecutor.java:603)
at java.lang.Thread.run(Thread.java:722)
{quote}
--
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
11 years