[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
[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, 1 month
[JBoss JIRA] Created: (SEAMSECURITY-91) cannot delete user/role/group in idmconsole example on glassfish3.1.1
by Tomáš Remeš (JIRA)
cannot delete user/role/group in idmconsole example on glassfish3.1.1
---------------------------------------------------------------------
Key: SEAMSECURITY-91
URL: https://issues.jboss.org/browse/SEAMSECURITY-91
Project: Seam Security
Issue Type: Bug
Environment: glassfish3.1.1, seam-security-3.1.0.Beta2
Reporter: Tomáš Remeš
deletion fails:
Exception [EclipseLink-6089] (Eclipse Persistence Services - 2.3.0.v20110604-r9504): org.eclipse.persistence.exceptions.QueryException
Exception Description: The expression has not been initialized correctly. Only a single ExpressionBuilder should be used for a query.
For parallel expressions, the query class must be provided to the ExpressionBuilder constructor, and the query's ExpressionBuilder must
always be on the left side of the expression.
Expression: [
Base org.jboss.seam.security.examples.idmconsole.model.IdentityObjectRelationship]
Query: ReadAllQuery(referenceClass=IdentityObjectRelationship )
at org.eclipse.persistence.exceptions.QueryException.noExpressionBuilderFound(QueryException.java:877)
at org.eclipse.persistence.expressions.ExpressionBuilder.getDescriptor(ExpressionBuilder.java:195)
at org.eclipse.persistence.internal.expressions.DataExpression.getMapping(DataExpression.java:214)
at org.eclipse.persistence.internal.expressions.QueryKeyExpression.getMapping(QueryKeyExpression.java:388)
at org.eclipse.persistence.internal.expressions.RelationExpression.isObjectComparison(RelationExpression.java:452)
at org.eclipse.persistence.internal.expressions.RelationExpression.normalize(RelationExpression.java:517)
at org.eclipse.persistence.internal.expressions.SQLSelectStatement.normalize(SQLSelectStatement.java:1300)
at org.eclipse.persistence.internal.queries.ExpressionQueryMechanism.buildNormalSelectStatement(ExpressionQueryMechanism.java:516)
at org.eclipse.persistence.internal.queries.ExpressionQueryMechanism.prepareSelectAllRows(ExpressionQueryMechanism.java:1602)
at org.eclipse.persistence.queries.ReadAllQuery.prepareSelectAllRows(ReadAllQuery.java:705)
at org.eclipse.persistence.queries.ReadAllQuery.prepare(ReadAllQuery.java:642)
at org.eclipse.persistence.queries.DatabaseQuery.checkPrepare(DatabaseQuery.java:598)
at org.eclipse.persistence.queries.ObjectLevelReadQuery.checkPrepare(ObjectLevelReadQuery.java:839)
at org.eclipse.persistence.queries.DatabaseQuery.checkPrepare(DatabaseQuery.java:560)
at org.eclipse.persistence.queries.DatabaseQuery.execute(DatabaseQuery.java:797)
at org.eclipse.persistence.queries.ObjectLevelReadQuery.execute(ObjectLevelReadQuery.java:1056)
at org.eclipse.persistence.queries.ReadAllQuery.execute(ReadAllQuery.java:390)
at org.eclipse.persistence.queries.ObjectLevelReadQuery.executeInUnitOfWork(ObjectLevelReadQuery.java:1144)
at org.eclipse.persistence.internal.sessions.UnitOfWorkImpl.internalExecuteQuery(UnitOfWorkImpl.java:2863)
at org.eclipse.persistence.internal.sessions.AbstractSession.executeQuery(AbstractSession.java:1501)
at org.eclipse.persistence.internal.sessions.AbstractSession.executeQuery(AbstractSession.java:1483)
at org.eclipse.persistence.internal.sessions.AbstractSession.executeQuery(AbstractSession.java:1457)
at org.eclipse.persistence.internal.jpa.EJBQueryImpl.executeReadQuery(EJBQueryImpl.java:485)
at org.eclipse.persistence.internal.jpa.EJBQueryImpl.getResultList(EJBQueryImpl.java:742)
at org.jboss.seam.security.management.picketlink.JpaIdentityStore.removeRelationships(JpaIdentityStore.java:1404)
at org.jboss.seam.security.management.picketlink.JpaIdentityStore.removeIdentityObject(JpaIdentityStore.java:1243)
at org.picketlink.idm.impl.repository.WrapperIdentityStoreRepository.removeIdentityObject(WrapperIdentityStoreRepository.java:158)
at org.picketlink.idm.impl.api.session.managers.PersistenceManagerImpl.removeUser(PersistenceManagerImpl.java:231)
at org.jboss.seam.security.management.action.UserAction.deleteUser(UserAction.java:116)
at org.jboss.seam.security.management.action.org$jboss$weld$bean-WEB-INF$lib$seam-security-3$1$0$Beta2-ManagedBean-org$jboss$seam$security$management$action$UserAction$@javax$enterprise$context$ConversationScoped()@javax$inject$Named(value=)${org$jboss$seam$security$management$action$UserAction$conversation$@javax$inject$Inject()$$org$jboss$seam$security$management$action$UserAction$identitySession$@javax$inject$Inject()$$org$jboss$seam$security$management$action$UserAction$deleteUser$@org$jboss$seam$transaction$Transactional(value=REQUIRED)@org$jboss$seam$transaction$TransactionalInterceptorBinding()$(java$lang$String)$org$jboss$seam$security$management$action$UserAction$save$@org$jboss$seam$transaction$Transactional(value=REQUIRED)@org$jboss$seam$transaction$TransactionalInterceptorBinding()$()$}_$$_WeldClientProxy.deleteUser(org$jboss$weld$bean-WEB-INF$lib$seam-security-3$1$0$Beta2-ManagedBean-org$jboss$seam$security$management$action$UserAction$@javax$enterprise$context$ConversationScoped()@javax$inject$Named(value=)${org$jboss$seam$security$management$action$UserAction$conversation$@javax$inject$Inject()$$org$jboss$seam$security$management$action$UserAction$identitySession$@javax$inject$Inject()$$org$jboss$seam$security$management$action$UserAction$deleteUser$@org$jboss$seam$transaction$Transactional(value=REQUIRED)@org$jboss$seam$transaction$TransactionalInterceptorBinding()$(java$lang$String)$org$jboss$seam$security$management$action$UserAction$save$@org$jboss$seam$transaction$Transactional(value=REQUIRED)@org$jboss$seam$transaction$TransactionalInterceptorBinding()$()$}_$$_WeldClientProxy.java)
at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method)
at sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:39)
at sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:25)
at java.lang.reflect.Method.invoke(Method.java:597)
at javax.el.BeanELResolver.invokeMethod(BeanELResolver.java:737)
at javax.el.BeanELResolver.invoke(BeanELResolver.java:467)
at javax.el.CompositeELResolver.invoke(CompositeELResolver.java:254)
at com.sun.el.parser.AstValue.invoke(AstValue.java:228)
at com.sun.el.MethodExpressionImpl.invoke(MethodExpressionImpl.java:297)
at org.jboss.weld.util.el.ForwardingMethodExpression.invoke(ForwardingMethodExpression.java:43)
at org.jboss.weld.el.WeldMethodExpression.invoke(WeldMethodExpression.java:56)
at com.sun.faces.facelets.el.TagMethodExpression.invoke(TagMethodExpression.java:105)
at javax.faces.component.MethodBindingMethodExpressionAdapter.invoke(MethodBindingMethodExpressionAdapter.java:88)
at com.sun.faces.application.ActionListenerImpl.processAction(ActionListenerImpl.java:102)
at javax.faces.component.UICommand.broadcast(UICommand.java:315)
at javax.faces.component.UIData.broadcast(UIData.java:1093)
at javax.faces.component.UIViewRoot.broadcastEvents(UIViewRoot.java:794)
at javax.faces.component.UIViewRoot.processApplication(UIViewRoot.java:1259)
at com.sun.faces.lifecycle.InvokeApplicationPhase.execute(InvokeApplicationPhase.java:81)
at com.sun.faces.lifecycle.Phase.doPhase(Phase.java:101)
at com.sun.faces.lifecycle.LifecycleImpl.execute(LifecycleImpl.java:118)
at javax.faces.webapp.FacesServlet.service(FacesServlet.java:593)
at org.apache.catalina.core.StandardWrapper.service(StandardWrapper.java:1539)
at org.apache.catalina.core.ApplicationFilterChain.internalDoFilter(ApplicationFilterChain.java:343)
at org.apache.catalina.core.ApplicationFilterChain.doFilter(ApplicationFilterChain.java:217)
at org.jboss.seam.servlet.exception.CatchExceptionFilter.doFilter(CatchExceptionFilter.java:62)
at org.apache.catalina.core.ApplicationFilterChain.internalDoFilter(ApplicationFilterChain.java:256)
at org.apache.catalina.core.ApplicationFilterChain.doFilter(ApplicationFilterChain.java:217)
at org.jboss.seam.servlet.event.ServletEventBridgeFilter.doFilter(ServletEventBridgeFilter.java:72)
at org.apache.catalina.core.ApplicationFilterChain.internalDoFilter(ApplicationFilterChain.java:256)
at org.apache.catalina.core.ApplicationFilterChain.doFilter(ApplicationFilterChain.java:217)
at org.apache.catalina.core.StandardWrapperValve.invoke(StandardWrapperValve.java:279)
at org.apache.catalina.core.StandardContextValve.invoke(StandardContextValve.java:175)
at org.apache.catalina.core.StandardPipeline.doInvoke(StandardPipeline.java:655)
at org.apache.catalina.core.StandardPipeline.invoke(StandardPipeline.java:595)
at com.sun.enterprise.web.WebPipeline.invoke(WebPipeline.java:98)
at com.sun.enterprise.web.PESessionLockingStandardPipeline.invoke(PESessionLockingStandardPipeline.java:91)
at org.apache.catalina.core.StandardHostValve.invoke(StandardHostValve.java:162)
at org.apache.catalina.connector.CoyoteAdapter.doService(CoyoteAdapter.java:330)
at org.apache.catalina.connector.CoyoteAdapter.service(CoyoteAdapter.java:231)
at com.sun.enterprise.v3.services.impl.ContainerMapper.service(ContainerMapper.java:174)
at com.sun.grizzly.http.ProcessorTask.invokeAdapter(ProcessorTask.java:828)
at com.sun.grizzly.http.ProcessorTask.doProcess(ProcessorTask.java:725)
at com.sun.grizzly.http.ProcessorTask.process(ProcessorTask.java:1019)
at com.sun.grizzly.http.DefaultProtocolFilter.execute(DefaultProtocolFilter.java:225)
at com.sun.grizzly.DefaultProtocolChain.executeProtocolFilter(DefaultProtocolChain.java:137)
at com.sun.grizzly.DefaultProtocolChain.execute(DefaultProtocolChain.java:104)
at com.sun.grizzly.DefaultProtocolChain.execute(DefaultProtocolChain.java:90)
at com.sun.grizzly.http.HttpProtocolChain.execute(HttpProtocolChain.java:79)
at com.sun.grizzly.ProtocolChainContextTask.doCall(ProtocolChainContextTask.java:54)
at com.sun.grizzly.SelectionKeyContextTask.call(SelectionKeyContextTask.java:59)
at com.sun.grizzly.ContextTask.run(ContextTask.java:71)
at com.sun.grizzly.util.AbstractThreadPool$Worker.doWork(AbstractThreadPool.java:532)
at com.sun.grizzly.util.AbstractThreadPool$Worker.run(AbstractThreadPool.java:513)
at java.lang.Thread.run(Thread.java:662)
--
This message is automatically generated by JIRA.
For more information on JIRA, see: http://www.atlassian.com/software/jira
12 years, 1 month
[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><!--$NO-MVN-MAN-VER$ -->
</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, 1 month
[JBoss JIRA] Created: (SEAMCRON-6) Can we use @RequestScoped for @Asynchronous methods? How?
by Peter Royle (JIRA)
Can we use @RequestScoped for @Asynchronous methods? How?
---------------------------------------------------------
Key: SEAMCRON-6
URL: https://issues.jboss.org/browse/SEAMCRON-6
Project: Seam Cron
Issue Type: Task
Reporter: Peter Royle
Assignee: Peter Royle
This is one for investigation some time. It came up in this IRC chat:
IRC Transcript:
[11:10am] johnament: request scoped won't be active in a background thread.
[11:10am] PeteRoyle: ah true cos it's threadlocal?
[11:10am] johnament: which?
[11:11am] PeteRoyle: request scoped implementation
[11:11am] PeteRoyle: won't work in a background thread because the implementation of request scope uses threadlocal, is that right?
[11:11am] johnament: its essentially an HTTP request
[11:12am] PeteRoyle: right
[11:12am] PeteRoyle: I think the use case is valid though, do you agree?
[11:13am] johnament: its valid, but it breaks the CDI model, so to say
[11:13am] johnament: because you want to make your contextual objects available outside of your context
[11:14am] PeteRoyle: right yeah that makes sense
[11:14am] PeteRoyle: the request might be over
[11:14am] johnament: the only thing really available is going to be dependent or application scoped
[11:15am] johnament: the bigger question - which request?
[11:15am] PeteRoyle: well the one from which the @Asynch method was called - assuming we could hang onto it
[11:15am] PeteRoyle: hang onto the request that is
[11:16am] PeteRoyle: eg: a controller which @Injects a @RequestScoped Thing, then calls an @Asynchronous method
[11:17am] johnament: the only way it would work is to make request scope extend through your @asynch process is over.
[11:18am] PeteRoyle: The interceptor would have access to the correct @RequestScope. It would need to replicate it into the new thread. Would that be possible do you think?
[11:18am] johnament: i don't know how plausible/possible that even is.
[11:18am] PeteRoyle: yeah. I might leave that as something for investigation later. I'll JIRA it
[11:18am] johnament: jms does this by transporting the event over JMS, but loses the context.
--
This message is automatically generated by JIRA.
For more information on JIRA, see: http://www.atlassian.com/software/jira
12 years, 2 months