July 2011 - seam-issues - Jboss List Archives

[JBoss JIRA] Created: (SEAMXML-22) support collection and array virtual fields

by Dan Allen (JIRA)

support collection and array virtual fields ------------------------------------------- Key: SEAMXML-22 URL: https://jira.jboss.org/browse/SEAMXML-22 Project: Seam XML Configuration Issue Type: Feature Request Affects Versions: 3.0.0.Beta1 Reporter: Dan Allen Fix For: 3.0.0.Beta2 Add support for defining virtual fields that are of type collection or array. This should work already in theory, but no matter what I tried, I got errors, so it may simply be broken. There is also one piece missing. There needs to be a way to specify the collection type parameter (item type). I'm envisioning something like this: <List> <Integer/> <-- defines item type <app:DiceValues/> <value>1</value> <value>2</value> <value>3</value> <value>4</value> <value>5</value> <value>6</value> </List> defines the virtual field: @DiceValues List<Integer> anonymous; In the same way, we should support virtual arrays: <array> <Integer/> <app:DiceValues/> <value>1</value> <value>2</value> <value>3</value> <value>4</value> <value>5</value> <value>6</value> </array> producing: @DiceValues Integer[] anonymous; The nested element for the type is a bit awkward, though (I suggested it because it's currently how array's are typed). It would make more sense to use an attribute here: <List itemType="java.lang.Integer"> ... </List> Also, a way to control the implementation type: <List type="java.util.ArrayList" itemType="java.lang.Integer"> ... </List> Once working, there definitely needs to be an example (or two) added to the documentation. -- This message is automatically generated by JIRA. - For more information on JIRA, see: http://www.atlassian.com/software/jira

12 years, 6 months

4
5
0 / 0

[JBoss JIRA] Created: (SEAMXML-25) Introduce s:values tag

by Jozef Hartinger (JIRA)

Introduce s:values tag ---------------------- Key: SEAMXML-25 URL: https://issues.jboss.org/browse/SEAMXML-25 Project: Seam Config Issue Type: Feature Request Affects Versions: 3.0.0.Beta1 Reporter: Jozef Hartinger Priority: Minor Currently, it is quite verbose to populate a collection with configured object instances using the XML module. For example: Foo is a class having a collection (bars) of Bars <e:Foo> <e:bars> <s:value> <e:Bar id="1"/> </s:value> <s:value> <e:Bar id="2"/> </s:value> <s:value> <e:Bar id="3"/> </s:value> <s:value> <e:Bar id="4"/> </s:value> </e:bars> </e:Foo> If the s:values tag is introduced, it'll make the configuration less verbose <e:Foo> <e:bars> <s:values> <e:Bar id="1"/> <e:Bar id="2"/> <e:Bar id="3"/> <e:Bar id="4"/> </s:values> </e:bars> </e:Foo> -- This message is automatically generated by JIRA. - For more information on JIRA, see: http://www.atlassian.com/software/jira

12 years, 6 months

4
7
0 / 0

[JBoss JIRA] Created: (SOLDER-54) Expand documentation for generic beans

by Dan Allen (JIRA)

Expand documentation for generic beans -------------------------------------- Key: SOLDER-54 URL: https://issues.jboss.org/browse/SOLDER-54 Project: Seam Solder Issue Type: Feature Request Components: Documentation Affects Versions: 3.0.0.Beta1 Reporter: Dan Allen Assignee: Stuart Douglas Priority: Minor Fix For: 3.0.0.CR1 Expand the documentation for generic beans and add another example. This is a feature developers will need to see to understand, so the more ways to look at it, the better. -- This message is automatically generated by JIRA. - For more information on JIRA, see: http://www.atlassian.com/software/jira

12 years, 6 months

3
2
0 / 0

[JBoss JIRA] Created: (SOLDER-71) org.jboss.seam.solder.bean is in impl when it should be in api

by Stuart Douglas (JIRA)

org.jboss.seam.solder.bean is in impl when it should be in api -------------------------------------------------------------- Key: SOLDER-71 URL: https://issues.jboss.org/browse/SOLDER-71 Project: Seam Solder Issue Type: Bug Reporter: Stuart Douglas Assignee: Stuart Douglas -- This message is automatically generated by JIRA. - For more information on JIRA, see: http://www.atlassian.com/software/jira

12 years, 6 months

2
2
0 / 0

[jbossseam-issues] [JBoss JIRA] Created: (JBSEAM-4070) Remove restriction that seam-debug.jar must be loaded by the same classloader as jsf-facelets.jar

by Stuart Douglas (JIRA)

Remove restriction that seam-debug.jar must be loaded by the same classloader as jsf-facelets.jar ------------------------------------------------------------------------------------------------- Key: JBSEAM-4070 URL: https://jira.jboss.org/jira/browse/JBSEAM-4070 Project: Seam Issue Type: Patch Reporter: Stuart Douglas Attachments: statewriter-patch.diff If seam-debug.jar and jsf-facelets.jar are not in the same classloader a redirect loop occurs when the debug page is displayed. I have changed the StateWriterControl class to use reflection to access StateWriter. This also mean the StateWriterControl can be moved out of com.sun.facelets and into an org.jboss.seam package. -- 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

12 years, 6 months

5
7
0 / 0

[jbossseam-issues] [JBoss JIRA] Created: (JBSEAM-4185) ViewExpiredException is printed in the log even if i set log="false"

by Adrian Mitev (JIRA)

ViewExpiredException is printed in the log even if i set log="false" -------------------------------------------------------------------- Key: JBSEAM-4185 URL: https://jira.jboss.org/jira/browse/JBSEAM-4185 Project: Seam Issue Type: Bug Components: JSF Integration Affects Versions: 2.1.2.CR1 Reporter: Adrian Mitev Attachments: exception.txt See exception.txt for the stacktrace. This is what i have in pages.xml <exception class="javax.faces.application.ViewExpiredException" log="false"> <redirect view-id="/common/error.xhtml"> <message>#{messages.sessionTimeout}</message> </redirect> </exception> and the redirect is performed but i still see the exception in the log -- 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

12 years, 6 months

5
13
0 / 0

[JBoss JIRA] Created: (JBSEAM-4825) Migrate XSD/XML validation to maven plugin

by Marek Novotny (JIRA)

Migrate XSD/XML validation to maven plugin ------------------------------------------ Key: JBSEAM-4825 URL: https://issues.jboss.org/browse/JBSEAM-4825 Project: Seam 2 Issue Type: Task Components: Build Reporter: Marek Novotny Priority: Critical Fix For: 2.3.0.BETA1 There is XML/XSD validation of Seam schemas, configuration files etc. in build/validate.xml. Migrate these targets to currect maven build system. -- This message is automatically generated by JIRA. For more information on JIRA, see: http://www.atlassian.com/software/jira

12 years, 7 months

3
10
0 / 0

[jbossseam-issues] [JBoss JIRA] Created: (JBSEAM-2697) Add attribute to s:link tag to make creation of magic dataModelSelection URL parameter optional

by Wolfgang Schwendt (JIRA)

Add attribute to s:link tag to make creation of magic dataModelSelection URL parameter optional ----------------------------------------------------------------------------------------------- Key: JBSEAM-2697 URL: http://jira.jboss.com/jira/browse/JBSEAM-2697 Project: JBoss Seam Issue Type: Feature Request Components: JSF Controls Affects Versions: 2.0.1.GA Reporter: Wolfgang Schwendt Priority: Minor When an s:link component (org.jboss.seam.ui.component.UILink) is placed into a h:dataTable backed by a javax.faces.model.DataModel, the s:link automatically generates the magic token for the magic "dataModelSelection" parameter regardless of whether the latter is really needed or not. This can generate ugly URLs. The following example is particulary ugly: http://127.0.0.1:8080/seminaris/seminarDetails.seam?seminarId=2&dataModel... Without the "dataModelSelection" parameter, the URL would look much cleaner: http://127.0.0.1:8080/seminaris/seminarDetails.seam?semId=2 So my question: Couldn't we make the "dataModelSelection" parameter optional? (For example, by adding an attribute to the s:link tag). Btw: I'm aware that org.jboss.seam.ui.component.UISeamCommandBase.getUrl() is the culprit that triggers inclusion of the the dataModelSelection parameter, so I know how to remove the dataModelSelection parameter generation, but it would be nice if also the officially released Seam version allowed the deactivation of the magic token generation. Further, no magic token is generated if a UIDataTable is supplied by a normal List rather than a DataModel (cf. UISeamCommandBase.getSelection() ), but unfortunately there can be cases where it makes sense to supply the table data as DataModel rather than normal List. -- 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

12 years, 7 months

3
5
0 / 0

[jbossseam-issues] [JBoss JIRA] Created: (JBSEAM-4428) <s:decorate> tag gives a "[renderkit] 'for' attribute cannot be null" message when no EditableValueHolder is found

by Julien Kronegg (JIRA)

<s:decorate> tag gives a "[renderkit] 'for' attribute cannot be null" message when no EditableValueHolder is found ------------------------------------------------------------------------------------------------------------------ Key: JBSEAM-4428 URL: https://jira.jboss.org/jira/browse/JBSEAM-4428 Project: Seam Issue Type: Bug Affects Versions: 2.1.2.GA Environment: Seam 2.1.2.GA, http://fisheye.jboss.org/browse/Seam/branches/community/Seam_2_1/ui/src/m..., http://fisheye.jboss.org/browse/Seam/branches/community/Seam_2_1/ui/src/m... Reporter: Julien Kronegg Priority: Minor When a field is decorated using <s:decorate> with the default Seam template "edit.xhtml" on content without EditableValueHolder (i.e. editable elements such as <h:inputText>), the following warning is issued: WARN [renderkit] 'for' attribute cannot be null This occurs for example on the following code snippet: <s:decorate id="char" template="edit.xhtml"> <ui:define name="label">Characters Left:</ui:define> <h:outputText id="charLeft" value="#{smsClass.charLeft}"/> </s:decorate> The Seam edit.xhtml template is the following: <ui:composition xmlns="http://www.w3.org/1999/xhtml" xmlns:ui="http://java.sun.com/jsf/facelets" xmlns:h="http://java.sun.com/jsf/html" xmlns:f="http://java.sun.com/jsf/core" xmlns:s="http://jboss.com/products/seam/taglib"> <div class="prop"> <s:label styleClass="name #{invalid?'errors':''}"> <ui:insert name="label"/> <s:span styleClass="required" rendered="#{required}">*</s:span> </s:label> <span class="value #{invalid?'errors':''}"> <s:validateAll> <ui:insert/> </s:validateAll> </span> <span class="error"> <h:graphicImage value="/img/error.gif" rendered="#{invalid}" styleClass="errors"/> <s:message styleClass="errors"/> </span> </div> </ui:composition> This is caused by org.jboss.seam.ui.component.UIDecorate which gets the 'for' id by looking at the first available EditableValueHolder. When there is no such element, the 'for' id is null, hence the warning message (probably issued by the org.jboss.seam.ui.component.UIMessage parent class javax.faces.component.html.HtmlMessage). The warning message is very anonying and give no useful information on what is going wrong: this kind of messages takes a lot of time to track and makes a big impact on the developper productivity. The UIDecorate class should either: 1) display no error message (by either attaching the s:message tag to the s:decorate itself, or by avoid rendering the s:message) 2) display a more meaningfull message such as "No editable component found to attach the message in the decorate with id=xxx" (maybe to be combined with solution 1). -- 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

12 years, 8 months

2
1
0 / 0

[JBoss JIRA] Created: (SEAMFACES-187) Seam faces failes to deployt without Pretty faces on AS7

by George Gastaldi (JIRA)

Seam faces failes to deployt without Pretty faces on AS7 -------------------------------------------------------- Key: SEAMFACES-187 URL: https://issues.jboss.org/browse/SEAMFACES-187 Project: Seam Faces Issue Type: Bug Environment: JBoss AS7. Indigo, M2Eclipse Reporter: George Gastaldi When deploying a war file with only the dependency below, an error is thrown: {code:xml} <dependency> <groupId>org.jboss.seam.faces</groupId> <artifactId>seam-faces</artifactId> <version>3.0.2.Final</version> </dependency> {code} {code:java} 18:59:50,935 WARN [org.jboss.modules] (MSC service thread 1-4) Failed to define class org.jboss.seam.faces.rewrite.RewriteConfiguration in Module "deployment.exemplo-web.war:main" from Service Module Loader: java.lang.LinkageError: Failed to link org/jboss/seam/faces/rewrite/RewriteConfiguration (Module "deployment.exemplo-web.war:main" from Service Module Loader) at org.jboss.modules.ModuleClassLoader.defineClass(ModuleClassLoader.java:401) at org.jboss.modules.ModuleClassLoader.loadClassLocal(ModuleClassLoader.java:261) at org.jboss.modules.ModuleClassLoader$1.loadClassLocal(ModuleClassLoader.java:76) at org.jboss.modules.Module.loadModuleClass(Module.java:588) at org.jboss.modules.ModuleClassLoader.findClass(ModuleClassLoader.java:183) at org.jboss.modules.ConcurrentClassLoader.performLoadClassChecked(ConcurrentClassLoader.java:358) at org.jboss.modules.ConcurrentClassLoader.performLoadClass(ConcurrentClassLoader.java:307) at org.jboss.modules.ConcurrentClassLoader.loadClass(ConcurrentClassLoader.java:101) at org.jboss.as.weld.WeldModuleResourceLoader.classForName(WeldModuleResourceLoader.java:68) [jboss-as-weld-7.0.0.Final.jar:7.0.0.Final] at org.jboss.weld.bootstrap.BeanDeployer.addClass(BeanDeployer.java:83) [weld-core-1.1.2.AS7.jar:2011-07-06 12:26] at org.jboss.weld.bootstrap.BeanDeployer.addClasses(BeanDeployer.java:133) [weld-core-1.1.2.AS7.jar:2011-07-06 12:26] at org.jboss.weld.bootstrap.BeanDeployment.createBeans(BeanDeployment.java:191) [weld-core-1.1.2.AS7.jar:2011-07-06 12:26] at org.jboss.weld.bootstrap.WeldBootstrap.deployBeans(WeldBootstrap.java:368) [weld-core-1.1.2.AS7.jar:2011-07-06 12:26] at org.jboss.as.weld.WeldContainer.start(WeldContainer.java:81) [jboss-as-weld-7.0.0.Final.jar:7.0.0.Final] at org.jboss.as.weld.services.WeldService.start(WeldService.java:89) [jboss-as-weld-7.0.0.Final.jar:7.0.0.Final] at org.jboss.msc.service.ServiceControllerImpl$StartTask.run(ServiceControllerImpl.java:1765) at org.jboss.msc.service.ServiceControllerImpl$ClearTCCLTask.run(ServiceControllerImpl.java:2291) at java.util.concurrent.ThreadPoolExecutor$Worker.runTask(ThreadPoolExecutor.java:886) [:1.6.0_24] at java.util.concurrent.ThreadPoolExecutor$Worker.run(ThreadPoolExecutor.java:908) [:1.6.0_24] at java.lang.Thread.run(Thread.java:662) [:1.6.0_24] Caused by: java.lang.NoClassDefFoundError: com/ocpsoft/pretty/faces/spi/ConfigurationProvider at java.lang.ClassLoader.defineClass1(Native Method) [:1.6.0_24] at java.lang.ClassLoader.defineClassCond(ClassLoader.java:632) [:1.6.0_24] at java.lang.ClassLoader.defineClass(ClassLoader.java:616) [:1.6.0_24] at java.security.SecureClassLoader.defineClass(SecureClassLoader.java:141) [:1.6.0_24] at org.jboss.modules.ModuleClassLoader.defineClass(ModuleClassLoader.java:397) ... 19 more Caused by: java.lang.ClassNotFoundException: com.ocpsoft.pretty.faces.spi.ConfigurationProvider from [Module "deployment.exemplo-web.war:main" from Service Module Loader] at org.jboss.modules.ModuleClassLoader.findClass(ModuleClassLoader.java:191) at org.jboss.modules.ConcurrentClassLoader.performLoadClassChecked(ConcurrentClassLoader.java:358) at org.jboss.modules.ConcurrentClassLoader.performLoadClassChecked(ConcurrentClassLoader.java:330) at org.jboss.modules.ConcurrentClassLoader.performLoadClassChecked(ConcurrentClassLoader.java:330) at org.jboss.modules.ConcurrentClassLoader.performLoadClass(ConcurrentClassLoader.java:307) at org.jboss.modules.ConcurrentClassLoader.loadClass(ConcurrentClassLoader.java:101) ... 24 more {code} I believe this is due to having a class extending a Pretty faces class that is not on my lib, but that shouldn´t be required -- This message is automatically generated by JIRA. For more information on JIRA, see: http://www.atlassian.com/software/jira

12 years, 8 months

7
12
0 / 0

2024

2023

2022

2021

2020

2019

2018

2017

2016

2015

2014

2013

2012

2011

2010

2009

2008

2007

2006

seam-issues July 2011