[jbossseam-issues] [JBoss JIRA] Created: (JBSEAM-3008) Page fragment caching impossible with coarse-grained rendered attribute evaluation in JSF
by Christian Bauer (JIRA)
Page fragment caching impossible with coarse-grained rendered attribute evaluation in JSF
-----------------------------------------------------------------------------------------
Key: JBSEAM-3008
URL: http://jira.jboss.com/jira/browse/JBSEAM-3008
Project: Seam
Issue Type: Task
Components: JSF Controls, JSF Integration
Reporter: Christian Bauer
The evaluation of the JSF rendered="true|false" attribute conflicts with the Seam page fragment cache.
<s:cache region="test" key="foo123">
<h:outputText value="FOO" rendered="#{foo.bar}"/>
</s:cache>
The rendered attribute of the child components is ALWAYS evaluated, in potentially any JSF phase (especially APPLY REQUEST VALUES and RENDER RESPONSE of course). No switch or combination of JSF component settings and renderers is able to stop that evaluation; you can not say "Do not call isRendered() on any child component of <s:cache>".
So any rendered-attribute expression that is costly (e.g. rendered="#{not empty myBackingBean.resultList}") will not be cached. This also means that there is a disconnect between what is finally rendered by s:cache (some HTML from the cache) and what the evaluation of the rendered attribute might produce. This is extremely difficult to work around. One approach is to only use lightweight rendered="#{foo}" expressions that can be evaluated many times without much cost.
I don't see any way to fix this unless the JSF specification is changed and a more sane model of rendering/non-rendering switches is introduced. The rendered attribute is used for all kinds of purposes inside the JSF engine, most of them have nothing to do with rendering (e.g. it is used in APPLY REQUEST VALUES to detect which bindings need to be evaluated back onto the model).
--
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
16 years, 3 months
[jbossseam-issues] [JBoss JIRA] Created: (JBSEAM-2987) HibernateEntityQuery fails when using a Collection as a parameter in an restriction
by Scott Olcott (JIRA)
HibernateEntityQuery fails when using a Collection as a parameter in an restriction
-----------------------------------------------------------------------------------
Key: JBSEAM-2987
URL: http://jira.jboss.com/jira/browse/JBSEAM-2987
Project: Seam
Issue Type: Bug
Components: Framework
Affects Versions: 2.1.0.A1, 2.0.2.CR2
Environment: hibernate/tomcat
Reporter: Scott Olcott
HibernateEntityQuery fails when using a Collection object as a parameter in an restriction.
The private setParameters method in HibernateEntityQuery does not check to see if the parameter is a Collection before calling query.setParameter(name,value). In plain hibernate it needs to call the query.setParameterList method instead of the setParameter method. When passing a List as a parameter to a restriction a ClassCastException is thrown.
This is not an issue when using EntityQuery, because in JPA the setParameter method on org.hibernate.ejb.QueryImpl takes care of this for you.
--
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
16 years, 3 months
[jbossseam-issues] [JBoss JIRA] Created: (JBSEAM-1623) Problems with rendering emails with seam-email and IceFaces 1.6
by Karol Oslowski (JIRA)
Problems with rendering emails with seam-email and IceFaces 1.6
---------------------------------------------------------------
Key: JBSEAM-1623
URL: http://jira.jboss.com/jira/browse/JBSEAM-1623
Project: JBoss Seam
Issue Type: Bug
Components: ICE Faces Integration
Affects Versions: 1.2.1.GA
Environment: JBoss AS 4.0.5 GA with EJB3 installed (1.2.0.GA), project with Seam 1.2.1 GA,
Reporter: Karol Oslowski
Assigned To: Gregory Dick
Bug is quite simple to replicate. All u have to do is install jboss with ejb3 from the net installer http://labs.jboss.com/jemsinstaller/downloads version 1.2.0.GA. You also have to get the example applications from seam 1.2.1 GA, You have to configure the mail example as described in jboss forum linked to this bug and when trying to send an email there will be such exception:
04:18:32,140 INFO [MailSession] Creating JavaMail Session (l***:)
04:18:32,156 INFO [MailSession] connected to mail server
04:18:32,250 ERROR [MailExample] Error sending mail
java.lang.NullPointerException
at org.jboss.seam.mail.ui.UIMessage.getCharset(UIMessage.java:242)
at org.jboss.seam.mail.ui.AddressComponent.getInternetAddress(AddressComponent.java:29)
at org.jboss.seam.mail.ui.UIFrom.encodeBegin(UIFrom.java:27)
at org.jboss.seam.ui.JSF.renderChild(JSF.java:171)
at org.jboss.seam.ui.JSF.renderChildren(JSF.java:162)
at org.jboss.seam.mail.ui.UIMessage.encodeChildren(UIMessage.java:159)
at org.jboss.seam.ui.JSF.renderChild(JSF.java:174)
at org.jboss.seam.ui.JSF.renderChildren(JSF.java:162)
at org.jboss.seam.ui.facelet.FaceletsRenderer.renderFacelet(FaceletsRenderer.java:150)
at org.jboss.seam.ui.facelet.FaceletsRenderer.render(FaceletsRenderer.java:112)
at org.jboss.seam.example.mail.MailExample.send(MailExample.java:42)
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:585)
at org.jboss.seam.util.Reflections.invoke(Reflections.java:20)
at org.jboss.seam.intercept.RootInvocationContext.proceed(RootInvocationContext.java:31)
at org.jboss.seam.intercept.SeamInvocationContext.proceed(SeamInvocationContext.java:57)
at org.jboss.seam.interceptors.BijectionInterceptor.aroundInvoke(BijectionInterceptor.java:47)
at org.jboss.seam.intercept.SeamInvocationContext.proceed(SeamInvocationContext.java:69)
at org.jboss.seam.interceptors.ManagedEntityIdentityInterceptor.aroundInvoke(ManagedEntityIdentityInterceptor.java:37)
at org.jboss.seam.intercept.SeamInvocationContext.proceed(SeamInvocationContext.java:69)
at org.jboss.seam.interceptors.RollbackInterceptor.aroundInvoke(RollbackInterceptor.java:34)
at org.jboss.seam.intercept.SeamInvocationContext.proceed(SeamInvocationContext.java:69)
at org.jboss.seam.interceptors.MethodContextInterceptor.aroundInvoke(MethodContextInterceptor.java:27)
at org.jboss.seam.intercept.SeamInvocationContext.proceed(SeamInvocationContext.java:69)
at org.jboss.seam.intercept.RootInterceptor.invoke(RootInterceptor.java:103)
at org.jboss.seam.intercept.JavaBeanInterceptor.interceptInvocation(JavaBeanInterceptor.java:151)
at org.jboss.seam.intercept.JavaBeanInterceptor.invoke(JavaBeanInterceptor.java:87)
at org.jboss.seam.example.mail.MailExample_$$_javassist_19.send(MailExample_$$_javassist_19.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:585)
at com.sun.el.parser.AstValue.invoke(AstValue.java:174)
at com.sun.el.MethodExpressionImpl.invoke(MethodExpressionImpl.java:286)
at com.sun.facelets.el.TagMethodExpression.invoke(TagMethodExpression.java:68)
at com.sun.facelets.el.LegacyMethodBinding.invoke(LegacyMethodBinding.java:69)
at org.apache.myfaces.application.ActionListenerImpl.processAction(ActionListenerImpl.java:63)
at javax.faces.component.UICommand.broadcast(UICommand.java:106)
at javax.faces.component.UIViewRoot._broadcastForPhase(UIViewRoot.java:94)
at javax.faces.component.UIViewRoot.processApplication(UIViewRoot.java:168)
at org.apache.myfaces.lifecycle.LifecycleImpl.invokeApplication(LifecycleImpl.java:343)
at org.apache.myfaces.lifecycle.LifecycleImpl.execute(LifecycleImpl.java:86)
at com.icesoft.faces.webapp.http.core.ReceiveSendUpdates.renderCycle(ReceiveSendUpdates.java:57)
at com.icesoft.faces.webapp.http.core.ReceiveSendUpdates.service(ReceiveSendUpdates.java:45)
at com.icesoft.faces.webapp.http.core.IDVerifier.service(IDVerifier.java:25)
at com.icesoft.faces.webapp.http.servlet.BasicAdaptingServlet.service(BasicAdaptingServlet.java:16)
at com.icesoft.faces.webapp.http.servlet.ViewBoundAdaptingServlet.service(ViewBoundAdaptingServlet.java:44)
at com.icesoft.faces.webapp.http.servlet.PathDispatcher$Matcher.serviceOnMatch(PathDispatcher.java:52)
at com.icesoft.faces.webapp.http.servlet.PathDispatcher.service(PathDispatcher.java:29)
at com.icesoft.faces.webapp.http.servlet.MainSessionBoundServlet.service(MainSessionBoundServlet.java:97)
at com.icesoft.faces.webapp.http.servlet.SessionDispatcher.service(SessionDispatcher.java:35)
at com.icesoft.faces.webapp.http.servlet.PathDispatcher$Matcher.serviceOnMatch(PathDispatcher.java:52)
at com.icesoft.faces.webapp.http.servlet.PathDispatcher.service(PathDispatcher.java:29)
at com.icesoft.faces.webapp.http.servlet.MainServlet.service(MainServlet.java:85)
at javax.servlet.http.HttpServlet.service(HttpServlet.java:810)
at org.apache.catalina.core.ApplicationFilterChain.internalDoFilter(ApplicationFilterChain.java:252)
at org.apache.catalina.core.ApplicationFilterChain.doFilter(ApplicationFilterChain.java:173)
at org.apache.catalina.core.ApplicationDispatcher.invoke(ApplicationDispatcher.java:672)
at org.apache.catalina.core.ApplicationDispatcher.processRequest(ApplicationDispatcher.java:463)
at org.apache.catalina.core.ApplicationDispatcher.doForward(ApplicationDispatcher.java:359)
at org.apache.catalina.core.ApplicationDispatcher.forward(ApplicationDispatcher.java:301)
at com.icesoft.faces.webapp.xmlhttp.BlockingServlet.service(BlockingServlet.java:54)
at org.apache.catalina.core.ApplicationFilterChain.internalDoFilter(ApplicationFilterChain.java:252)
at org.apache.catalina.core.ApplicationFilterChain.doFilter(ApplicationFilterChain.java:173)
at org.jboss.seam.web.ExceptionFilter.doFilter(ExceptionFilter.java:57)
at org.apache.catalina.core.ApplicationFilterChain.internalDoFilter(ApplicationFilterChain.java:202)
at org.apache.catalina.core.ApplicationFilterChain.doFilter(ApplicationFilterChain.java:173)
at org.jboss.web.tomcat.filters.ReplyHeaderFilter.doFilter(ReplyHeaderFilter.java:96)
at org.apache.catalina.core.ApplicationFilterChain.internalDoFilter(ApplicationFilterChain.java:202)
at org.apache.catalina.core.ApplicationFilterChain.doFilter(ApplicationFilterChain.java:173)
at org.apache.catalina.core.StandardWrapperValve.invoke(StandardWrapperValve.java:213)
at org.apache.catalina.core.StandardContextValve.invoke(StandardContextValve.java:178)
at org.jboss.web.tomcat.security.SecurityAssociationValve.invoke(SecurityAssociationValve.java:175)
at org.jboss.web.tomcat.security.JaccContextValve.invoke(JaccContextValve.java:74)
at org.apache.catalina.core.StandardHostValve.invoke(StandardHostValve.java:126)
at org.apache.catalina.valves.ErrorReportValve.invoke(ErrorReportValve.java:105)
at org.jboss.web.tomcat.tc5.jca.CachedConnectionValve.invoke(CachedConnectionValve.java:156)
at org.apache.catalina.core.StandardEngineValve.invoke(StandardEngineValve.java:107)
at org.apache.catalina.connector.CoyoteAdapter.service(CoyoteAdapter.java:148)
at org.apache.coyote.http11.Http11Processor.process(Http11Processor.java:869)
at org.apache.coyote.http11.Http11BaseProtocol$Http11ConnectionHandler.processConnection(Http11BaseProtocol.java:664)
at org.apache.tomcat.util.net.PoolTcpEndpoint.processSocket(PoolTcpEndpoint.java:527)
at org.apache.tomcat.util.net.MasterSlaveWorkerThread.run(MasterSlaveWorkerThread.java:112)
at java.lang.Thread.run(Thread.java:595)
--
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
16 years, 3 months
[jbossseam-issues] [JBoss JIRA] Created: (JBSEAM-2773) JPA example on Tomcat 6.X throws a NoClassDefFoundError: org/objectweb/asm/Type
by Jay Balunas (JIRA)
JPA example on Tomcat 6.X throws a NoClassDefFoundError: org/objectweb/asm/Type
-------------------------------------------------------------------------------
Key: JBSEAM-2773
URL: http://jira.jboss.com/jira/browse/JBSEAM-2773
Project: JBoss Seam
Issue Type: Bug
Components: Examples, Platform interoperability
Affects Versions: 2.0.2.GA
Environment: Tomcat 6.0.16
Java 1.5
Linux fedora 8 x86
Reporter: Jay Balunas
Assigned To: Jay Balunas
Fix For: 2.0.2.GA, 2.1.0.BETA1
Follow the instructions for the JPA example deploying to tomcat 6.0. When deploying the JPA example you will see the exception below.
Caused by: java.lang.NoClassDefFoundError: org/objectweb/asm/Type
at net.sf.cglib.core.TypeUtils.parseType(TypeUtils.java:180)
at net.sf.cglib.core.KeyFactory.<clinit>(KeyFactory.java:66)
at net.sf.cglib.proxy.Enhancer.<clinit>(Enhancer.java:69)
at org.hibernate.proxy.pojo.cglib.CGLIBLazyInitializer.getProxyFactory(CGLIBLazyInitializer.java:117)
at org.hibernate.proxy.pojo.cglib.CGLIBProxyFactory.postInstantiate(CGLIBProxyFactory.java:43)
at org.hibernate.tuple.entity.PojoEntityTuplizer.buildProxyFactory(PojoEntityTuplizer.java:162)
at org.hibernate.tuple.entity.AbstractEntityTuplizer.<init>(AbstractEntityTuplizer.java:135)
at org.hibernate.tuple.entity.PojoEntityTuplizer.<init>(PojoEntityTuplizer.java:55)
at org.hibernate.tuple.entity.EntityEntityModeToTuplizerMapping.<init>(EntityEntityModeToTuplizerMapping.java:56)
at org.hibernate.tuple.entity.EntityMetamodel.<init>(EntityMetamodel.java:295)
at org.hibernate.persister.entity.AbstractEntityPersister.<init>(AbstractEntityPersister.java:434)
at org.hibernate.persister.entity.SingleTableEntityPersister.<init>(SingleTableEntityPersister.java:109)
at org.hibernate.persister.PersisterFactory.createClassPersister(PersisterFactory.java:55)
at org.hibernate.impl.SessionFactoryImpl.<init>(SessionFactoryImpl.java:226)
at org.hibernate.cfg.Configuration.buildSessionFactory(Configuration.java:1294)
at org.hibernate.cfg.AnnotationConfiguration.buildSessionFactory(AnnotationConfiguration.java:915)
at org.hibernate.ejb.Ejb3Configuration.buildEntityManagerFactory(Ejb3Configuration.java:730)
at org.hibernate.ejb.HibernatePersistence.createEntityManagerFactory(HibernatePersistence.java:121)
at javax.persistence.Persistence.createEntityManagerFactory(Persistence.java:83)
at javax.persistence.Persistence.createEntityManagerFactory(Persistence.java:60)
at org.jboss.seam.persistence.EntityManagerFactory.createEntityManagerFactory(EntityManagerFactory.java:81)
at org.jboss.seam.persistence.EntityManagerFactory.startup(EntityManagerFactory.java:50)
... 38 more
--
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
16 years, 3 months
[jbossseam-issues] [JBoss JIRA] Created: (JBSEAM-2666) ManagedPersistenceContext closed in a clustered environment
by Clint Popetz (JIRA)
ManagedPersistenceContext closed in a clustered environment
-----------------------------------------------------------
Key: JBSEAM-2666
URL: http://jira.jboss.com/jira/browse/JBSEAM-2666
Project: JBoss Seam
Issue Type: Bug
Components: Core
Affects Versions: 2.0.1.GA
Reporter: Clint Popetz
Attachments: mpc-passivate.diff
ManagedPersistenceContext, upon passivation, checks to see if the entity manager is dirty, and if not, closes it. I presume this is intended as an optimization. But in a clustered environment, where a snapshot of the session is taken upon each request that dirties the session, passivation will occur frequently within a conversation. In this case, the entity manager is frequently closed and recreated upon the next request, and entities in conversational beans become detached, and all sorts of bad things happen when I try to use them in the new session.
I think that to preserve the promise of long conversations, we have to keep the persistence context open across passivation, regardless of whether it's dirty.
The attached patch removes the entityManager close().
--
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
16 years, 3 months
[jbossseam-issues] [JBoss JIRA] Created: (JBSEAM-1228) Add sort option to <s:selectItems>
by Stephan Bublava (JIRA)
Add sort option to <s:selectItems>
----------------------------------
Key: JBSEAM-1228
URL: http://jira.jboss.com/jira/browse/JBSEAM-1228
Project: JBoss Seam
Issue Type: Patch
Components: JSF
Affects Versions: 1.2.1.GA
Reporter: Stephan Bublava
Attachments: sort-selectitems-patch.txt
The attached patch adds a sort option to <s:selectItems>, that allows the entries to be sorted by their label.
Example:
<h:selectOneMenu value="#{person.honorific}">
<s:selectItems value="#{honorifics}" var="honorific" label="#{honorific.label}" noSelectionLabel="Please select" sort="ascending" />
<s:convertEnum />
</h:selectOneMenu>
This version has not been tested in depth (especially interactions with "noSelectionLabel"), but I've been using similar code in our project (based upon Seam SelectItems 1.1.1beta1) for some time now and not encountered any problems.
--
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
16 years, 3 months
[jbossseam-issues] [JBoss JIRA] Created: (JBSEAM-1981) enable validation on file upload component
by Bruno Bieth (JIRA)
enable validation on file upload component
------------------------------------------
Key: JBSEAM-1981
URL: http://jira.jboss.com/jira/browse/JBSEAM-1981
Project: JBoss Seam
Issue Type: Patch
Reporter: Bruno Bieth
Currently file upload can't be validated.
The attached patch allow to use the hibernate validation framework with byte[] attribute.
You may have, for instance, to check if an uploaded file is an Image.
About the patch :
First the submittedValue is not set so the validation phase is skipped, second file upload doesn't use the standard "value" attribute (needed by the ModelValidator) but "data".
To work you have to use a value attribute to your fileupload component. At the moment this work only with Facelets. For backward compatibility the data attribute is kept (but validation won't work).
--
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
16 years, 3 months