[jbossseam-issues] [JBoss JIRA] Created: (JBSEAM-1922) Back button doesn't work with PAGE scope and JSF-RI Server state saving
by Michael Youngstrom (JIRA)
Back button doesn't work with PAGE scope and JSF-RI Server state saving
-----------------------------------------------------------------------
Key: JBSEAM-1922
URL: http://jira.jboss.com/jira/browse/JBSEAM-1922
Project: JBoss Seam
Issue Type: Bug
Components: Core
Affects Versions: 2.0.0.BETA1
Reporter: Michael Youngstrom
JSF doesn't make any guarentees about the isolation of attributes stored in the view. Because of this a PAGE scoped component that gets passed along to several views will actually be a single instance when using Server state management with the RI.
This causes a problem with back button support for the PAGE scope (imho the main difference of PAGE scope over CONVERSATION). For example:
@Name("test")
@Scope(PAGE)
public class Test implements Serializable {
private int value = 0;
public int getValue() {
return value;
}
public void incValue() {
value++;
}
}
Value = #{test.value}
<h:form>
<h:commandButton action="#{test.incValue}" value="Increment Value"/>
</h:form>
Test Case when using Server side state management:
1. I view the page: "Value = 0" Displayed
2. I press "Increment" button: "Value = 1"
3. I press "Increment" button: "Value = 2"
4. I press "back" button: "Value = 1"
5. I press "Increment" button: "Value=3"
If running in client state mode Step 5 displays "Value=2".
To make PAGE scope work consistently between client and server JSF state management we need to figure out some way to serialize PAGE scoped values when doing "saveState" or something so that a new instance of PAGE is accessed from restore-view of any subsequent requests.
Here is a link to a conversation on the RI about this issue:
https://javaserverfaces.dev.java.net/servlets/BrowseList?list=dev&by=thre...
>From the conversation it appears the MyFaces is not effected by this issue by default.
--
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
17 years, 4 months
[jbossseam-issues] [JBoss JIRA] Created: (JBSEAM-2485) NoClassDefFound when a service bean interface is in an outside .jar
by Adam Warski (JIRA)
NoClassDefFound when a service bean interface is in an outside .jar
-------------------------------------------------------------------
Key: JBSEAM-2485
URL: http://jira.jboss.com/jira/browse/JBSEAM-2485
Project: JBoss Seam
Issue Type: Bug
Affects Versions: 2.0.1.CR1, 2.0.0.GA
Environment: JBoss AS 4.2.2, 4.2.1, Seam 2.0.0.GA, 2.0.1.CR1
Reporter: Adam Warski
My deployment is as follows:
- MyApi.jar, which contains the local an interface for a stateless session bean
- MyApp.ear, which is a normal Seam application, and has an implementation of the interface
The api is in a separate jar so that I can use the SLSB in other applications.
On some occasions, I got weird exceptions, like:
Caused by: java.lang.RuntimeException: by java.lang.NoClassDefFoundError: org/jboss/seam/intercept/Proxy
at org.jboss.seam.util.ProxyFactory.createClass(ProxyFactory.java:190)
or
Caused by: java.lang.RuntimeException: by java.lang.NoClassDefFoundError: org/jboss/seam/Instance
at org.jboss.seam.util.ProxyFactory.createClass(ProxyFactory.java:190)
(full example stack trace below).
I think the reason is as follows:
in org.jboss.seam.Component.createProxyFactory(...) - lines 2234-2254, a set of interfaces is created. It is a HashSet, so the first element may differ on each invocation of the method (that's why the exception is thrown only sometimes).
This set contains both the business interfaces, as well as org/jboss/seam/Instance, org/jboss/seam/intercept/Proxy.
Then, in org.jboss.seam.util.ProxyFactory.getClassLoader (lines 196-212) (which is invoked from the previously mentioned method), a classloader is obtained, which is later used to load all the interfaces classes and instantiate the proxy (in javassist). The classloader is taken to be the classloader of the first interface in the interfaces array (which is constructed from the set).
So, the classloader may be that of:
(1) the business interface
(2) org/jboss/seam/Instance, org/jboss/seam/intercept/Proxy.
If it is number (2), then it is the scoped classloader of the ear. However, if it is (1), then it is the unified class loader which was used to load the .jar, which contains the business interface. This classloader cannot load the org/jboss/seam/intercept/Proxy and org/jboss/seam/Component interfaces, as they are contained in a scoped deployment. Thus, an exception is thrown.
A fix which I have right now is, in org.jboss.seam.Component.createProxyFactory:
1. replace HashSet with LinkedHashSet - then the first element will always be the same
2. move adding the org/jboss/seam/intercept/Proxy and org/jboss/seam/Component interfaces to the top, so that the scoped class loader is later obtained in org.jboss.seam.util.ProxyFactory.getClassLoader.
I've tested it and it seems to fix the issue.
And finally the promised stack trace:
javax.el.ELException: /home.xhtml: Could not instantiate Seam component: serviceBean
at com.sun.facelets.compiler.TextInstruction.write(TextInstruction.java:50)
at com.sun.facelets.compiler.UIInstructions.encodeBegin(UIInstructions.java:39)
at org.ajax4jsf.renderkit.RendererBase.renderChild(RendererBase.java:280)
at org.ajax4jsf.renderkit.RendererBase.renderChildren(RendererBase.java:262)
at org.richfaces.renderkit.html.PanelRenderer.doEncodeChildren(PanelRenderer.java:199)
at org.richfaces.renderkit.html.PanelRenderer.doEncodeChildren(PanelRenderer.java:194)
at org.ajax4jsf.renderkit.RendererBase.encodeChildren(RendererBase.java:121)
at javax.faces.component.UIComponentBase.encodeChildren(UIComponentBase.java:812)
at javax.faces.component.UIComponent.encodeAll(UIComponent.java:886)
at javax.faces.component.UIComponent.encodeAll(UIComponent.java:892)
at com.sun.facelets.FaceletViewHandler.renderView(FaceletViewHandler.java:592)
at org.ajax4jsf.application.ViewHandlerWrapper.renderView(ViewHandlerWrapper.java:108)
at org.ajax4jsf.application.AjaxViewHandler.renderView(AjaxViewHandler.java:216)
at com.sun.faces.lifecycle.RenderResponsePhase.execute(RenderResponsePhase.java:106)
at com.sun.faces.lifecycle.LifecycleImpl.phase(LifecycleImpl.java:251)
at com.sun.faces.lifecycle.LifecycleImpl.render(LifecycleImpl.java:144)
at javax.faces.webapp.FacesServlet.service(FacesServlet.java:245)
at org.apache.catalina.core.ApplicationFilterChain.internalDoFilter(ApplicationFilterChain.java:290)
at org.apache.catalina.core.ApplicationFilterChain.doFilter(ApplicationFilterChain.java:206)
at org.jboss.seam.servlet.SeamFilter$FilterChainImpl.doFilter(SeamFilter.java:83)
at org.jboss.seam.debug.hot.HotDeployFilter.doFilter(HotDeployFilter.java:68)
at org.jboss.seam.servlet.SeamFilter$FilterChainImpl.doFilter(SeamFilter.java:69)
at org.jboss.seam.web.MultipartFilter.doFilter(MultipartFilter.java:85)
at org.jboss.seam.servlet.SeamFilter$FilterChainImpl.doFilter(SeamFilter.java:69)
at org.jboss.seam.web.ExceptionFilter.doFilter(ExceptionFilter.java:64)
at org.jboss.seam.servlet.SeamFilter$FilterChainImpl.doFilter(SeamFilter.java:69)
at org.jboss.seam.web.RedirectFilter.doFilter(RedirectFilter.java:45)
at org.jboss.seam.servlet.SeamFilter$FilterChainImpl.doFilter(SeamFilter.java:69)
at org.ajax4jsf.webapp.BaseXMLFilter.doXmlFilter(BaseXMLFilter.java:141)
at org.ajax4jsf.webapp.BaseFilter.doFilter(BaseFilter.java:281)
at org.jboss.seam.web.Ajax4jsfFilter.doFilter(Ajax4jsfFilter.java:60)
at org.jboss.seam.servlet.SeamFilter$FilterChainImpl.doFilter(SeamFilter.java:69)
at org.jboss.seam.web.LoggingFilter.doFilter(LoggingFilter.java:58)
at org.jboss.seam.servlet.SeamFilter$FilterChainImpl.doFilter(SeamFilter.java:69)
at org.jboss.seam.servlet.SeamFilter.doFilter(SeamFilter.java:158)
at org.apache.catalina.core.ApplicationFilterChain.internalDoFilter(ApplicationFilterChain.java:235)
at org.apache.catalina.core.ApplicationFilterChain.doFilter(ApplicationFilterChain.java:206)
at org.jboss.web.tomcat.filters.ReplyHeaderFilter.doFilter(ReplyHeaderFilter.java:96)
at org.apache.catalina.core.ApplicationFilterChain.internalDoFilter(ApplicationFilterChain.java:235)
at org.apache.catalina.core.ApplicationFilterChain.doFilter(ApplicationFilterChain.java:206)
at org.apache.catalina.core.StandardWrapperValve.invoke(StandardWrapperValve.java:230)
at org.apache.catalina.core.StandardContextValve.invoke(StandardContextValve.java:175)
at org.jboss.web.tomcat.security.SecurityAssociationValve.invoke(SecurityAssociationValve.java:179)
at org.apache.catalina.authenticator.AuthenticatorBase.invoke(AuthenticatorBase.java:432)
at org.jboss.web.tomcat.security.JaccContextValve.invoke(JaccContextValve.java:84)
at org.apache.catalina.core.StandardHostValve.invoke(StandardHostValve.java:127)
at org.apache.catalina.valves.ErrorReportValve.invoke(ErrorReportValve.java:102)
at org.jboss.web.tomcat.service.jca.CachedConnectionValve.invoke(CachedConnectionValve.java:157)
at org.apache.catalina.core.StandardEngineValve.invoke(StandardEngineValve.java:109)
at org.apache.catalina.connector.CoyoteAdapter.service(CoyoteAdapter.java:262)
at org.apache.coyote.http11.Http11Processor.process(Http11Processor.java:844)
at org.apache.coyote.http11.Http11Protocol$Http11ConnectionHandler.process(Http11Protocol.java:583)
at org.apache.tomcat.util.net.JIoEndpoint$Worker.run(JIoEndpoint.java:446)
at java.lang.Thread.run(Thread.java:613)
Caused by: org.jboss.seam.InstantiationException: Could not instantiate Seam component: serviceBean
at org.jboss.seam.Component.newInstance(Component.java:1970)
at org.jboss.seam.Component.getInstance(Component.java:1873)
at org.jboss.seam.Component.getInstance(Component.java:1840)
at org.jboss.seam.Namespace.getComponentInstance(Namespace.java:55)
at org.jboss.seam.Namespace.getComponentInstance(Namespace.java:50)
at org.jboss.seam.el.SeamELResolver.resolveBase(SeamELResolver.java:166)
at org.jboss.seam.el.SeamELResolver.getValue(SeamELResolver.java:53)
at javax.el.CompositeELResolver.getValue(CompositeELResolver.java:53)
at com.sun.faces.el.FacesCompositeELResolver.getValue(FacesCompositeELResolver.java:64)
at org.jboss.el.parser.AstIdentifier.getValue(AstIdentifier.java:44)
at org.jboss.el.parser.AstValue.getValue(AstValue.java:63)
at org.jboss.el.ValueExpressionImpl.getValue(ValueExpressionImpl.java:186)
at com.sun.facelets.el.ELText$ELTextVariable.writeText(ELText.java:184)
at com.sun.facelets.el.ELText$ELTextComposite.writeText(ELText.java:108)
at com.sun.facelets.compiler.TextInstruction.write(TextInstruction.java:45)
... 53 more
Caused by: java.lang.RuntimeException: by java.lang.NoClassDefFoundError: org/jboss/seam/intercept/Proxy
at org.jboss.seam.util.ProxyFactory.createClass(ProxyFactory.java:190)
at org.jboss.seam.Component.createProxyFactory(Component.java:2260)
at org.jboss.seam.Component.getProxyFactory(Component.java:1375)
at org.jboss.seam.Component.wrap(Component.java:1366)
at org.jboss.seam.Component.instantiateSessionBean(Component.java:1288)
at org.jboss.seam.Component.instantiate(Component.java:1273)
at org.jboss.seam.Component.newInstance(Component.java:1966)
... 67 more
Caused by: javassist.CannotCompileException: by java.lang.NoClassDefFoundError: org/jboss/seam/intercept/Proxy
at javassist.util.proxy.FactoryHelper.toClass(FactoryHelper.java:165)
at org.jboss.seam.util.ProxyFactory.createClass(ProxyFactory.java:186)
... 73 more
Caused by: java.lang.NoClassDefFoundError: org/jboss/seam/intercept/Proxy
at java.lang.ClassLoader.defineClass1(Native Method)
at java.lang.ClassLoader.defineClass(ClassLoader.java:620)
at sun.reflect.GeneratedMethodAccessor264.invoke(Unknown Source)
at sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:25)
at java.lang.reflect.Method.invoke(Method.java:585)
at javassist.util.proxy.FactoryHelper.toClass2(FactoryHelper.java:177)
at javassist.util.proxy.FactoryHelper.toClass(FactoryHelper.java:159)
... 74 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
17 years, 4 months
[jbossseam-issues] [JBoss JIRA] Created: (JBSEAM-2794) Make Seam EL more extensible and unified
by Michael Youngstrom (JIRA)
Make Seam EL more extensible and unified
----------------------------------------
Key: JBSEAM-2794
URL: http://jira.jboss.com/jira/browse/JBSEAM-2794
Project: JBoss Seam
Issue Type: Feature Request
Components: Core
Affects Versions: 2.1.0.A1
Reporter: Michael Youngstrom
Assigned To: Michael Youngstrom
Fix For: 2.1.0.BETA2
I'm currently having some trouble dealing with ELResolvers in Seam and JSF.
1. It is not very easy to add ELResolvers to Seam (e.g. SpringELResolver must be put in the end of the resolver chain when it should be one of the first.)
2. When executing outside a FacesRequest you have to use the Seam ELResolver infrastructure which doesn't see any of the JSF ELResolvers
3. It would be nice to have a little more control over the order of ELResolvers since I have run into a few recursive situations as EL can sometimes sneak it's way into situations where EL is used in the SeamELResolver to resolve EL.
I believe that all of the above can be solved by:
1. Turn the SeamELResolver into a CompositeELResolver where a Seam Component can manage the included ELResolvers.
2. Add the above single SeamCompositeELResolver to the faces-context.xml. Making it so custom ELResolvers can be managed in a single place in Seam for both Faces and non Faces requests.
--
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
17 years, 4 months
[jbossseam-issues] [JBoss JIRA] Created: (JBSEAM-2704) Performance during iteration (datatable, repeat) in the UI with value bindings that run through interceptors
by Siarhei Dudzin (JIRA)
Performance during iteration (datatable, repeat) in the UI with value bindings that run through interceptors
------------------------------------------------------------------------------------------------------------
Key: JBSEAM-2704
URL: http://jira.jboss.com/jira/browse/JBSEAM-2704
Project: JBoss Seam
Issue Type: Bug
Components: Performance and Scalability
Affects Versions: 2.0.1.GA, 2.0.0.GA
Environment: Seam 2.0.0, 2.0.1
Reporter: Siarhei Dudzin
"Since we don't cache this, a particular backing bean might be called hundreds or thousands of times during rendering of a datatable, if a value binding has to be evaluated for each row. If the backing bean is a Seam component, injection of dependencies will occur for every call, involving potentially thousands of map lookups."
There is a discussion thread with a bit more data: http://www.seamframework.org/Community/SeamPerformanceOptimization
The issue is also recognized at the seamframework.org site itself: http://www.seamframework.org/Documentation/TuningTheSeamWebsite#H-Iterati...
Since the issue it known, this JIRA report is created for better traceability.
--
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
17 years, 5 months
[jbossseam-issues] [JBoss JIRA] Created: (JBSEAM-2562) 'Transaction failed' JSF message when number of restriction in EntityQuery changes
by Siarhei Dudzin (JIRA)
'Transaction failed' JSF message when number of restriction in EntityQuery changes
----------------------------------------------------------------------------------
Key: JBSEAM-2562
URL: http://jira.jboss.com/jira/browse/JBSEAM-2562
Project: JBoss Seam
Issue Type: Bug
Components: Framework
Affects Versions: 2.0.1.GA
Environment: JBoss AS 4.2.2, Windows XP
Reporter: Siarhei Dudzin
When getRestrictions() from EntityQuerry returns dynamic list with restrictions a JSF error message 'Transaction failed' is shown (no exceptions just a message). I noticed this happens when the size of the list is decreased in comparison with the previous request (There is also a warning in the logs).
While this JSF message is shown the query still works!
After some debugging I've found that the underlying error is that a value binding could not be found. A temprorarily workaround is to keep the restriction list constant by filling the 'gaps' with placeholders like #{true}=true (just to keep the size constant).
--
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
17 years, 5 months