[JBoss JIRA] (RF-13686) Props interfaces overlap and are not fully implemented
by Michal Petrov (JIRA)
[ https://issues.jboss.org/browse/RF-13686?page=com.atlassian.jira.plugin.s... ]
Michal Petrov commented on RF-13686:
------------------------------------
I've noticed AbstractAutocomplete still references the xml files and even though they are not part of the project they still seem to be used by CDK somehow. (AbstractAutocomplete defines getTabIndex but the @Attribute annotation is missing and yet the generated UIAutocomplete has a getTabindex method).
> Props interfaces overlap and are not fully implemented
> ------------------------------------------------------
>
> Key: RF-13686
> URL: https://issues.jboss.org/browse/RF-13686
> Project: RichFaces
> Issue Type: Enhancement
> Security Level: Public(Everyone can see)
> Affects Versions: 4.5.0.Alpha3
> Reporter: Michal Petrov
> Assignee: Michal Petrov
> Fix For: 4.5.0.Beta1
>
>
> In addition to RF-13679 - @styleClass is also defined in CoreProps which many classes implement and in several classes it is hardcoded (like AbstractAutocomplete), several other interfaces are not being implemented.
--
This message was sent by Atlassian JIRA
(v6.2.6#6264)
9 years, 11 months
[JBoss JIRA] (RF-13723) fileUpload: 'Clear All' button does not work after maxFilesQuantity reached on IE
by Michal Petrov (JIRA)
[ https://issues.jboss.org/browse/RF-13723?page=com.atlassian.jira.plugin.s... ]
Michal Petrov commented on RF-13723:
------------------------------------
Clicking on an element should produce {{mousedown}}, {{mouseup}} and {{click}} events but in this case the click event never fires. I can't tell why it is happening, running a profiler produces the same results up until the mouseup event.
> fileUpload: 'Clear All' button does not work after maxFilesQuantity reached on IE
> ---------------------------------------------------------------------------------
>
> Key: RF-13723
> URL: https://issues.jboss.org/browse/RF-13723
> Project: RichFaces
> Issue Type: Bug
> Security Level: Public(Everyone can see)
> Components: component-input
> Affects Versions: 4.5.0.Alpha3
> Environment: IE 11, IE 10
> Reporter: Jiří Štefek
> Priority: Minor
> Labels: IE10, IE11
> Fix For: 4.5.0.Beta1
>
>
> The 'Clear All' button does nothing when clicked after maxFilesQuantity reached by adding items using the 'Add' button. It works after items were added by DnD.
> You have to click somewhere on the page, to get the button working.
> It works fine in FF, Chrome.
--
This message was sent by Atlassian JIRA
(v6.2.6#6264)
9 years, 11 months
[JBoss JIRA] (RF-13724) Showcase - leftovers of old Editor skinning setup cause 404 error
by Juraj Húska (JIRA)
[ https://issues.jboss.org/browse/RF-13724?page=com.atlassian.jira.plugin.s... ]
Juraj Húska closed RF-13724.
----------------------------
Verified. Closing.
> Showcase - leftovers of old Editor skinning setup cause 404 error
> -----------------------------------------------------------------
>
> Key: RF-13724
> URL: https://issues.jboss.org/browse/RF-13724
> Project: RichFaces
> Issue Type: Bug
> Security Level: Public(Everyone can see)
> Components: showcase
> Affects Versions: 4.5.0.Alpha3
> Reporter: Juraj Húska
> Assignee: Juraj Húska
> Priority: Trivial
> Fix For: 4.5.0.Beta1
>
>
> In the example for editor advanced configuration, there is leftover of old skinning setup:
> {code:xml}
> <h:form>
> <a4j:outputPanel style="display:none">
> <rich:editor skin="kama" />
> <rich:editor skin="v2" />
> <rich:editor skin="office2003" />
> </a4j:outputPanel>
> </h:form>
> {code}
> This causes 404 HTTP errors, while those skins can not be found in the resources.
> Note that this errors do not affect any functionality nor they are somehow visible elsewhere than in JS console.
--
This message was sent by Atlassian JIRA
(v6.2.6#6264)
9 years, 11 months
[JBoss JIRA] (RF-13725) Showcase can not be deployed on Tomcat 7 due to Weld & Guava integration
by Juraj Húska (JIRA)
[ https://issues.jboss.org/browse/RF-13725?page=com.atlassian.jira.plugin.s... ]
Juraj Húska closed RF-13725.
----------------------------
Verified. Closing.
> Showcase can not be deployed on Tomcat 7 due to Weld & Guava integration
> ------------------------------------------------------------------------
>
> Key: RF-13725
> URL: https://issues.jboss.org/browse/RF-13725
> Project: RichFaces
> Issue Type: Bug
> Security Level: Public(Everyone can see)
> Components: showcase
> Affects Versions: 4.5.0.Alpha3
> Reporter: Juraj Húska
> Assignee: Michal Petrov
> Fix For: 4.5.0.Beta1
>
>
> Showcase can not be deployed on Tomcat 7. Following exception, closely related to guava & Weld, is thrown:
> {code}
> SEVERE: Error configuring application listener of class org.jboss.weld.environment.servlet.Listener
> java.lang.IllegalAccessError: tried to access method com.google.common.collect.MapMaker.makeComputingMap(Lcom/google/common/base/Function;)Ljava/util/concurrent/ConcurrentMap; from class org.jboss.weld.logging.WeldMessageConveyor
> at org.jboss.weld.logging.WeldMessageConveyor.<init>(WeldMessageConveyor.java:61)
> at org.jboss.weld.logging.WeldMessageConveyerFactory.getDefaultMessageConveyer(WeldMessageConveyerFactory.java:27)
> at org.jboss.weld.logging.LoggerFactory.<init>(LoggerFactory.java:37)
> at org.jboss.weld.logging.LoggerFactory.loggerFactory(LoggerFactory.java:51)
> at org.jboss.weld.bootstrap.WeldBootstrap.<clinit>(WeldBootstrap.java:124)
> at sun.reflect.NativeConstructorAccessorImpl.newInstance0(Native Method)
> at sun.reflect.NativeConstructorAccessorImpl.newInstance(NativeConstructorAccessorImpl.java:57)
> at sun.reflect.DelegatingConstructorAccessorImpl.newInstance(DelegatingConstructorAccessorImpl.java:45)
> at java.lang.reflect.Constructor.newInstance(Constructor.java:526)
> at java.lang.Class.newInstance(Class.java:374)
> at org.jboss.weld.environment.servlet.util.Reflections.newInstance(Reflections.java:36)
> at org.jboss.weld.environment.servlet.Listener.<init>(Listener.java:70)
> at sun.reflect.NativeConstructorAccessorImpl.newInstance0(Native Method)
> at sun.reflect.NativeConstructorAccessorImpl.newInstance(NativeConstructorAccessorImpl.java:57)
> at sun.reflect.DelegatingConstructorAccessorImpl.newInstance(DelegatingConstructorAccessorImpl.java:45)
> at java.lang.reflect.Constructor.newInstance(Constructor.java:526)
> at java.lang.Class.newInstance(Class.java:374)
> at org.apache.catalina.core.DefaultInstanceManager.newInstance(DefaultInstanceManager.java:140)
> at org.apache.catalina.core.StandardContext.listenerStart(StandardContext.java:4888)
> at org.apache.catalina.core.StandardContext.startInternal(StandardContext.java:5467)
> at org.apache.catalina.util.LifecycleBase.start(LifecycleBase.java:150)
> at org.apache.catalina.core.ContainerBase.addChildInternal(ContainerBase.java:901)
> at org.apache.catalina.core.ContainerBase.addChild(ContainerBase.java:877)
> at org.apache.catalina.core.StandardHost.addChild(StandardHost.java:632)
> at org.apache.catalina.startup.HostConfig.deployWAR(HostConfig.java:1083)
> at org.apache.catalina.startup.HostConfig$DeployWar.run(HostConfig.java:1880)
> at java.util.concurrent.Executors$RunnableAdapter.call(Executors.java:471)
> at java.util.concurrent.FutureTask.run(FutureTask.java:262)
> at java.util.concurrent.ThreadPoolExecutor.runWorker(ThreadPoolExecutor.java:1145)
> at java.util.concurrent.ThreadPoolExecutor$Worker.run(ThreadPoolExecutor.java:615)
> at java.lang.Thread.run(Thread.java:745)
> {code}
--
This message was sent by Atlassian JIRA
(v6.2.6#6264)
9 years, 11 months
[JBoss JIRA] (RF-13733) dataTable built-in sorting
by Edward I (JIRA)
Edward I created RF-13733:
-----------------------------
Summary: dataTable built-in sorting
Key: RF-13733
URL: https://issues.jboss.org/browse/RF-13733
Project: RichFaces
Issue Type: Enhancement
Security Level: Public (Everyone can see)
Components: component-tables
Affects Versions: 4.3.7
Reporter: Edward I
dataTable built-in sorting is still not implemented - only implemented in extendedDataTable so far. Is this still being planned?
--
This message was sent by Atlassian JIRA
(v6.2.6#6264)
9 years, 11 months
[JBoss JIRA] (RF-8125) Tables: built-in sorting/filtering
by Patrick Schmidt (JIRA)
[ https://issues.jboss.org/browse/RF-8125?page=com.atlassian.jira.plugin.sy... ]
Patrick Schmidt commented on RF-8125:
-------------------------------------
METZLER Clerk
-----------------------------------------------------------------------
Patrick Schmidt
Ich bin abwesend und ausschließlich freitag vormittags im Haus und werde
Ihre E-Mail dann bearbeiten. In dringenden Fällen wenden Sie sich bitte an
Martin Winzer (mwinzer(a)metzler.com).
> Tables: built-in sorting/filtering
> ----------------------------------
>
> Key: RF-8125
> URL: https://issues.jboss.org/browse/RF-8125
> Project: RichFaces
> Issue Type: Feature Request
> Security Level: Public(Everyone can see)
> Components: component-tables
> Affects Versions: 4.0.0.Final
> Reporter: Anton Belevich
> Assignee: Brian Leathem
> Fix For: 4.3.0.M3
>
> Original Estimate: 2 days
> Remaining Estimate: 2 days
>
--
This message was sent by Atlassian JIRA
(v6.2.6#6264)
9 years, 11 months
[JBoss JIRA] (RF-13719) rich.fileUpload breaks form action in portal
by Brian Leathem (JIRA)
[ https://issues.jboss.org/browse/RF-13719?page=com.atlassian.jira.plugin.s... ]
Brian Leathem updated RF-13719:
-------------------------------
Comment: was deleted
(was: Jonáš Trantina <jtrantin(a)redhat.com> changed the Status of [bug 1120627|https://bugzilla.redhat.com/show_bug.cgi?id=1120627] from NEW to CLOSED)
> rich.fileUpload breaks form action in portal
> --------------------------------------------
>
> Key: RF-13719
> URL: https://issues.jboss.org/browse/RF-13719
> Project: RichFaces
> Issue Type: Feature Request
> Security Level: Public(Everyone can see)
> Components: component-input
> Affects Versions: 4.3.5
> Environment: JBoss Portal 6.1.1
> Reporter: Jonáš Trantina
> Labels: gss
> Attachments: reproducer.zip, reproducer2.zip
>
>
> When a rich:fileUpload si submitted (i.e. files are uploaded) action of the form is not preserved well.
> In fileupload.js __submit method there is the following code:
> {code:JavaScript}
> var encodedURLInputs = this.form.children("input[name='javax.faces.encodedURL']");
> var originalAction = encodedURLInputs.length > 0 ? encodedURLInputs.val() : this.form.attr("action");
> {code}
> the var "originalAction" is then used to revert to the original action url of the form. However, encodedURLInputs and form action prop does not contain the same url. Because encodedURLInputs has bigger priority URL from that input is restored into the form and not the original form action. This breaks the form as the next submission fails.
> In portal the solution is
> {code:JavaScript}
> var originalFormAction =this.form.attr("action");
> {code}
> and then restore "originalFormAction" instead of "originalAction", but I am not sure if this doesn't break anything in other environments.
> Is this a bug in richfaces or is the content of input[name='javax.faces.encodedURL'] set badly?
> To reproduce you can use the reproducer attached.
> Example URLs:
> form action
> {code}
> /portal/classic/home/uploadform?portal:componentId=834fa198-ff3d-4a5c-a1c7-33c85e8a410d&interactionstate=JBPNS_rO0ABXcsABBfanNmQnJpZGdlVmlld0lkAAAAAQALL2hvbWUueGh0bWwAB19fRU9GX18*&portal:type=action
> {code}
> input[name='javax.faces.encodedURL']
> {code}
> /portal/classic/home/uploadform?portal:windowState=normal&portal:componentId=834fa198-ff3d-4a5c-a1c7-33c85e8a410d&portal:cacheLevel=PAGE&resourcestate=JBPNS_rO0ABXdAABBfanNmQnJpZGdlVmlld0lkAAAAAQALL2hvbWUueGh0bWwACF9wYnJBamF4AAAAAQAEdHJ1ZQAHX19FT0ZfXw**&portal:type=resource&portal:portletMode=view
> {code}
--
This message was sent by Atlassian JIRA
(v6.2.6#6264)
9 years, 11 months
[JBoss JIRA] (RF-13719) rich.fileUpload breaks form action in portal
by Brian Leathem (JIRA)
[ https://issues.jboss.org/browse/RF-13719?page=com.atlassian.jira.plugin.s... ]
Brian Leathem updated RF-13719:
-------------------------------
Comment: was deleted
(was: A comment with security level 'Red Hat' was removed.)
> rich.fileUpload breaks form action in portal
> --------------------------------------------
>
> Key: RF-13719
> URL: https://issues.jboss.org/browse/RF-13719
> Project: RichFaces
> Issue Type: Feature Request
> Security Level: Public(Everyone can see)
> Components: component-input
> Affects Versions: 4.3.5
> Environment: JBoss Portal 6.1.1
> Reporter: Jonáš Trantina
> Labels: gss
> Attachments: reproducer.zip, reproducer2.zip
>
>
> When a rich:fileUpload si submitted (i.e. files are uploaded) action of the form is not preserved well.
> In fileupload.js __submit method there is the following code:
> {code:JavaScript}
> var encodedURLInputs = this.form.children("input[name='javax.faces.encodedURL']");
> var originalAction = encodedURLInputs.length > 0 ? encodedURLInputs.val() : this.form.attr("action");
> {code}
> the var "originalAction" is then used to revert to the original action url of the form. However, encodedURLInputs and form action prop does not contain the same url. Because encodedURLInputs has bigger priority URL from that input is restored into the form and not the original form action. This breaks the form as the next submission fails.
> In portal the solution is
> {code:JavaScript}
> var originalFormAction =this.form.attr("action");
> {code}
> and then restore "originalFormAction" instead of "originalAction", but I am not sure if this doesn't break anything in other environments.
> Is this a bug in richfaces or is the content of input[name='javax.faces.encodedURL'] set badly?
> To reproduce you can use the reproducer attached.
> Example URLs:
> form action
> {code}
> /portal/classic/home/uploadform?portal:componentId=834fa198-ff3d-4a5c-a1c7-33c85e8a410d&interactionstate=JBPNS_rO0ABXcsABBfanNmQnJpZGdlVmlld0lkAAAAAQALL2hvbWUueGh0bWwAB19fRU9GX18*&portal:type=action
> {code}
> input[name='javax.faces.encodedURL']
> {code}
> /portal/classic/home/uploadform?portal:windowState=normal&portal:componentId=834fa198-ff3d-4a5c-a1c7-33c85e8a410d&portal:cacheLevel=PAGE&resourcestate=JBPNS_rO0ABXdAABBfanNmQnJpZGdlVmlld0lkAAAAAQALL2hvbWUueGh0bWwACF9wYnJBamF4AAAAAQAEdHJ1ZQAHX19FT0ZfXw**&portal:type=resource&portal:portletMode=view
> {code}
--
This message was sent by Atlassian JIRA
(v6.2.6#6264)
9 years, 11 months