[JBoss JIRA] Created: (RF-11191) components/dist/ui does not include taglibs
by Lukáš Fryč (JIRA)
components/dist/ui does not include taglibs
-------------------------------------------
Key: RF-11191
URL: https://issues.jboss.org/browse/RF-11191
Project: RichFaces
Issue Type: Bug
Security Level: Public (Everyone can see)
Components: build/distribution
Affects Versions: 4.1.0.Milestone1
Reporter: Lukáš Fryč
maven-shade-plugin in components/dist/richfaces-components-ui does not generate target/taglibs.
These are generated after initial installation and then separated build of richfaces-components-ui,
but not in complete framework build.
This leads into invalid VDL-DOC content.
--
This message is automatically generated by JIRA.
For more information on JIRA, see: http://www.atlassian.com/software/jira
13 years
[JBoss JIRA] Created: (RF-7501) HtmlPanelMenu should support recursive node adaptor
by arne anka (JIRA)
HtmlPanelMenu should support recursive node adaptor
---------------------------------------------------
Key: RF-7501
URL: https://jira.jboss.org/jira/browse/RF-7501
Project: RichFaces
Issue Type: Feature Request
Components: component-menu
Reporter: arne anka
i'd like to use HtmlPanelMenu to display a rather big structure like below where the nodes reach about 300 and take a considerable lot of time to create the menu from scratch.
my idea was to create the deeper levels (Level B and Level C nodes) only when the Level A node is expaned, like one can do with rich:tree and rich:recursiveTreeNodesAdaptor -- but there's not really a way to do that.
thus, having some kind like treeNodesRecursiveAdaptor would make live certainly easier.
imo all of these expandable structures should by default support an model or adaptor or whatever it is called.
Level A
|--Level B
|--Level C
|--Level C
|--Level C
|--Level B
|--Level C
|--Level C
Level A
|--Level B
|--Level C
|--Level C
|--Level C
|--Level B
|--Level C
|--Level C
--
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
13 years
[JBoss JIRA] Created: (RF-10984) rich:tree selectionType=server throws Exception
by u j (JIRA)
rich:tree selectionType=server throws Exception
-----------------------------------------------
Key: RF-10984
URL: https://issues.jboss.org/browse/RF-10984
Project: RichFaces
Issue Type: Bug
Security Level: Public (Everyone can see)
Components: component-tree
Affects Versions: 4.0.0.Final
Reporter: u j
The component reference for RichFaces 4 states that rich:tree selectionType can be "server", but:
17:35:25,373 GRAVE [javax.enterprise.resource.webcontainer.jsf.application] Error Rendering View[/searchestab.xhtml]: java.lang.IllegalArgumentException: server
at org.richfaces.renderkit.TreeRendererBase.getSelectionType(TreeRendererBase.java:164) [:4.0.0-SNAPSHOT]
at org.richfaces.renderkit.html.TreeRenderer.encodeEnd(TreeRenderer.java:154) [:4.0.0-SNAPSHOT]
at javax.faces.component.UIComponentBase.encodeEnd(UIComponentBase.java:879) [:2.0.3-]
which is obvious in the code:
protected SwitchType getSelectionType(FacesContext context, UIComponent component) {
AbstractTree tree = (AbstractTree) component;
SwitchType selectionType = getSelectionTypeOrDefault(tree);
if (selectionType != SwitchType.ajax && selectionType != SwitchType.client) {
//TODO - better message
throw new IllegalArgumentException(String.valueOf(selectionType));
}
return selectionType;
}
See also
http://community.jboss.org/message/604516#604516
--
This message is automatically generated by JIRA.
For more information on JIRA, see: http://www.atlassian.com/software/jira
13 years, 1 month
[JBoss JIRA] (RF-11557) showcase - deployment on JBoss AS 7.1.0-SNAPSHOT - "topic not ready yet, sleeping" is logged constantly
by Juraj Huska (Created) (JIRA)
showcase - deployment on JBoss AS 7.1.0-SNAPSHOT - "topic not ready yet, sleeping" is logged constantly
-------------------------------------------------------------------------------------------------------
Key: RF-11557
URL: https://issues.jboss.org/browse/RF-11557
Project: RichFaces
Issue Type: Bug
Security Level: Public (Everyone can see)
Components: showcase
Affects Versions: 4.1.0.Milestone3
Environment: app: richfaces-showcase-4.1.0.20111014-M3
container - JBoss AS 7.1.0-Alpha2-Snapshot
Reporter: Juraj Huska
After successfully deployed showcase application on JBoss AS 7.1.0-Alpha2-Snapshot, following warn is constantly logged to container output:
{code}
19:26:47,874 SEVERE [org.richfaces.demo.push.TopicsInitializer] (RegisterTopicThread) topic pushTopicsContext not ready yet, sleeping
19:26:47,873 SEVERE [org.richfaces.demo.push.TopicsInitializer] (RegisterTopicThread) topic pushCdi not ready yet, sleeping
19:26:48,374 SEVERE [org.richfaces.demo.push.TopicsInitializer] (RegisterTopicThread) topic pushJms not ready yet, sleeping
{code}
This behavior is *regression* which was already fixed. There is no JIRA for that.
This *is not noticeable on JBoss AS 7.x stable releases.*
I am enclosing the full starting log of AS.
--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators: https://issues.jboss.org/secure/ContactAdministrators!default.jspa
For more information on JIRA, see: http://www.atlassian.com/software/jira
13 years, 1 month
[JBoss JIRA] Created: (RF-11447) extendedDataTable re-rendering
by Brendan Healey (JIRA)
extendedDataTable re-rendering
-------------------------------
Key: RF-11447
URL: https://issues.jboss.org/browse/RF-11447
Project: RichFaces
Issue Type: Bug
Security Level: Public (Everyone can see)
Affects Versions: 4.0.0.Final
Environment: Mojarra 2.1.3.
Reporter: Brendan Healey
I've got a h:selectOneMenu inside a column of an extendedDataTable which can
be used to modify a property of the current row. The changeInviteState
valueChangeListener persists the modification to the database. What I would
expect to happen in the below example is that the getEventTeamList() method
returns the current data, selectOneMenu is used to make a change and the
nested "<a4j:ajax render="teamTable"/>" causes the table to be re-rendered
(the table getter getEventTeamList should be called to refresh the data).
The problem is that this re-rendering of the table doesn't happen. I see the
value change listener firing but the table value getter is not executed after
the VCL.
The importance of being able to re-render the table after the data change is
that when using optimistic locking the table will contain a stale version
number and subsequent modification attempts will fail (unless you refresh the
data before making a modification, but that is an inferior approach).
Note that removing <a4j:ajax event="selectionchange" makes no difference.
<rich:extendedDataTable
id="teamTable"
binding="#{bean.teamTable}"
value="#{bean.eventTeamList}" var="var"
selectionMode="single"
selection="#{bean.selectedTeamRow}">
<a4j:ajax event="selectionchange"
listener="#{bean.teamRowSelect}"/>
<rich:column style="text-align: center">
<h:selectOneMenu value="#{var.inviteState}"
immediate="true"
valueChangeListener="#{bean.changeInviteState}"
rendered="#{bean.showStatusInput}">
<f:selectItems value="#{bean.teamStatusOptions}"
var="svar" itemLabel="#{svar.localName}" itemValue="#{svar}"/>
<a4j:ajax render="teamTable"/>
</h:selectOneMenu>
</rich:column>
</rich:extendedDataTable>
--
This message is automatically generated by JIRA.
For more information on JIRA, see: http://www.atlassian.com/software/jira
13 years, 1 month