March 2009 - seam-issues - Jboss List Archives

[jbossseam-issues] [JBoss JIRA] Created: (JBSEAM-3916) SeamELResolver.resolveInMap() will resolve a property "size" to ((Map)base).size() even if the Map contains a key named "base" - instead, it should return null and allow javax.el.MapELResolver to resolve the property to ((Map)base).get("size")

by Ian Springer (JIRA)

SeamELResolver.resolveInMap() will resolve a property "size" to ((Map)base).size() even if the Map contains a key named "base" - instead, it should return null and allow javax.el.MapELResolver to resolve the property to ((Map)base).get("size") --------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------- Key: JBSEAM-3916 URL: https://jira.jboss.org/jira/browse/JBSEAM-3916 Project: Seam Issue Type: Bug Components: EL Affects Versions: 2.1.0.SP1 Reporter: Ian Springer Priority: Critical I have an expression: #{MyBean.someMap['size']} In my non-Seam JSF app, this expression was resolving to MyBean.getSomeMap().get("size"). However, when I integrated Seam into my app, the expression started instead resolving to MyBean.getSomeMap().size(), which broke my app. This is occurring because SeamELResolver is ahead of javax.el.MapELResolver in the CompositeELResolver resolver list, and its resolveInMap() function ensures a property named "size" resolves to ((Map)base).size() This makes it impossible for me to obtain the value of the element with key "size" from my Map via EL. To solve this, I suggest changing SeamELResolver.resolveInMap() to the following: private Object resolveInMap(ELContext context, Object base, Object property) { if ( !( (Map) base ).containsKey("size") && "size".equals(property) ) { context.setPropertyResolved(true); return ( (Map) base ).size(); } else if ( !( (Map) base ).containsKey("values") && "values".equals(property) ) { context.setPropertyResolved(true); return ( (Map) base ).values(); } else if ( !( (Map) base ).containsKey("keySet") && "keySet".equals(property) ) { context.setPropertyResolved(true); return ( (Map) base ).keySet(); } else if ( !( (Map) base ).containsKey("entrySet") && "entrySet".equals(property) ) { context.setPropertyResolved(true); return ( (Map) base ).entrySet(); } else { return null; } } The only disadvantage of this is that if you actually are trying to get at map.size(), there will be no way to do so if the Map happens to contain a key named "size". However, in such a case, #{MyBean.someMap.keySet.size} or #{MyBean.someMap.values.size} could instead be used to obtain the Map's size. -- 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

15 years, 9 months

3
7
0 / 0

[jbossseam-issues] [JBoss JIRA] Created: (JBSEAM-4025) Page actions do not work without Facelets

by Hideyuki Suzumi (JIRA)

Page actions do not work without Facelets ----------------------------------------- Key: JBSEAM-4025 URL: https://jira.jboss.org/jira/browse/JBSEAM-4025 Project: Seam Issue Type: Bug Affects Versions: 2.1.1.GA Reporter: Hideyuki Suzumi I updated seam 2.0.2.SP1 to 2.1.1.GA. I updated .page.xml to refer to the 2.1 XSD. However, page actions did not work. .page.xml is ignored. I debugged and found the cause. org.jboss.seam.navigation.Pages [line: 158] String viewId = "/" + fileName.substring(0,fileName.length()-".page.xml".length()) + ".xhtml"; // needs more here I am using not facelets but jsp. -- 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

15 years, 9 months

1
0
0 / 0

[jbossseam-issues] [JBoss JIRA] Created: (JBSEAM-4024) Exception logging doesn't work in page action

by Salvatore Insalaco (JIRA)

Exception logging doesn't work in page action --------------------------------------------- Key: JBSEAM-4024 URL: https://jira.jboss.org/jira/browse/JBSEAM-4024 Project: Seam Issue Type: Bug Components: Exception Handling Affects Versions: 2.1.1.GA Reporter: Salvatore Insalaco When an exception is managed by Seam, configured in pages.xml, it's logged if the parameter "log='true'" is present. This doesn't work for exceptions raised during a page action call: the exception is correctly handled as described in pages.xml, but it is never logged, ignoring the "log" attribute. To try it: 1) Create a standard seam-gen project. 2) Create a component with an action that has "raise new Exception()" in his body. 3) Associate that action to a commandButton: the exception is logged. 4) Associate the same action to a page action: the exception is not logged anymore. -- 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

15 years, 9 months

1
0
0 / 0

[jbossseam-issues] [JBoss JIRA] Created: (JBSEAM-3383) REST @Context injection for Seam component resources

by Christian Bauer (JIRA)

REST @Context injection for Seam component resources ---------------------------------------------------- Key: JBSEAM-3383 URL: https://jira.jboss.org/jira/browse/JBSEAM-3383 Project: Seam Issue Type: Bug Components: WS Reporter: Christian Bauer Assignee: Christian Bauer Priority: Critical The JAX-RS @Context annotation on fields does not work for JAX-RS resources when the resource class is a Seam component (instantiated and intercepted by Seam). AFAIK the fields annotated with @Context are injected with a proxy when instantiated by Resteasy. When Seam instantiates and manages the object, the proxy isn't injected. Need to find out how Resteasy does that and port it/call it from a Seam interceptor. -- 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

15 years, 9 months

1
1
0 / 0

[jbossseam-issues] [JBoss JIRA] Created: (JBSEAM-3673) horizontalAlignment="right" broken in PDF cells (regression)

by Dan Allen (JIRA)

horizontalAlignment="right" broken in PDF cells (regression) ------------------------------------------------------------ Key: JBSEAM-3673 URL: https://jira.jboss.org/jira/browse/JBSEAM-3673 Project: Seam Issue Type: Bug Components: PDF Affects Versions: 2.1.0.SP1 Reporter: Dan Allen Fix For: 2.1.1.CR1 All of a sudden the horizontal alignment on PDF cells stopped working in Seam 2.1. You can see the discrepancy by deploying the iText example in Seam 2.0 and Seam 2.1 and observing the servlet path /seam-itext/format.seam. You'll notice that the Order Summary table is formatted differently in the two cases, with the right-hand alignment not taking affect under Seam 2.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

15 years, 9 months

7
17
0 / 0

[jbossseam-issues] [JBoss JIRA] Created: (JBSEAM-4023) share seam classes betwee webapps

by David Schlotfeldt (JIRA)

share seam classes betwee webapps --------------------------------- Key: JBSEAM-4023 URL: https://jira.jboss.org/jira/browse/JBSEAM-4023 Project: Seam Issue Type: Feature Request Reporter: David Schlotfeldt Priority: Minor It would be nice if we didn't have to package seam jars with ever webapp. We attempted putting the seam jar in the shared lib directory but doing so causes JSF webapps that don't have the seam servlet-listener in place get a NPE when you make a request to the site. This happens because the faces-config.xml in the seam jar is loaded by all JSF webapps -- so even the ones with one the servlet-listener load it. Keeping the seam jar in shared location will greatly decrease perm gen space usage for those with multiple seam webapps. Possible solutions: A) remove faces-config.xml from the jboss-seam jar. Place it in a new jar. Each webapp that needs seam then includes the new jar that only contains the faces-config.xml (This is the current solution I am using B) rename the faces-config.xml file in the jar so its not auto loaded. Then make the servlet-listener some how load it. (If this is technically possible this is of course the best solution since it is "backwards compatible".) Thanks! -- 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

15 years, 9 months

2
1
0 / 0

[jbossseam-issues] [JBoss JIRA] Created: (JBSEAM-2589) gen-ui: order of fields in generated forms

by Stephan Grter (JIRA)

gen-ui: order of fields in generated forms ------------------------------------------ Key: JBSEAM-2589 URL: http://jira.jboss.com/jira/browse/JBSEAM-2589 Project: JBoss Seam Issue Type: Feature Request Affects Versions: 2.0.1.GA Environment: Mac OS X 10.4.10 PPC, Java 1.5.0_13-121, JBoss-AS 4.2.2.GA, Seam 2.0.1.GA, PostgreSQL 8.2.4 Reporter: Stephan Grter When I generate the xhtml files from existing entities, then the entry fields will be displayed in alphabetical order of the entity properties and not in the order of declaration. For rapid prototyping it would be desirable, if the fields would appear in the order of declaration. Since the fields in the auto generated database table are in the the order of declaration, this should be possible for gen-ui as well. -- 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

15 years, 9 months

8
12
0 / 0

[jbossseam-issues] [JBoss JIRA] Created: (JBSEAM-2347) ComponentScanner fails with classes in WEB-INF/classes on websphere

by Norman Richards (JIRA)

ComponentScanner fails with classes in WEB-INF/classes on websphere ------------------------------------------------------------------- Key: JBSEAM-2347 URL: http://jira.jboss.com/jira/browse/JBSEAM-2347 Project: JBoss Seam Issue Type: Bug Reporter: Norman Richards Assigned To: Norman Richards Priority: Minor Fix For: 2.0.1.GA If looks like websphere adds the WAR contents directly to the classpath, which causes scanner errors when loading: java.lang.NoClassDefFoundError: WEB-INF.classes.com.somecompany.SomeComponent I'll fix the scanner as soon as I've verified the issue on websphere. -- 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

15 years, 9 months

2
2
0 / 0

[jbossseam-issues] [JBoss JIRA] Created: (JBSEAM-3645) Support co-existence of multiple view layers in same deployment

by Clint Popetz (JIRA)

Support co-existence of multiple view layers in same deployment --------------------------------------------------------------- Key: JBSEAM-3645 URL: https://jira.jboss.org/jira/browse/JBSEAM-3645 Project: Seam Issue Type: Patch Reporter: Clint Popetz Attachments: multi-view.diff Currently one must choose between wicket and jsf when using seam, because the wicket support works by overriding certain faces components. This patch eliminates that limitation. This patch should be applied after the patches from the issues linked to this issue, which are also related to wicket development. There are four parts of this patch. (1) The Manager and StatusMessages components are currently implemented in jsf with FacesManager and FacesMessages, and in wicket with WicketManager and WicketStatusMessages. Since a mixed deployment would need all managers to be @Installed, this patch makes each have a separate @Name, and makes the base classes (Manager and StatusMessages) @Unwrap themselves as one of the subclass components. Each subclass component registers itself with the base class component (by observing the postInitialization event) as a possible implementation. When Manager.instance() or StatusMessages.instance() is invoked, and the base component is created, @Unwrap is called, and that method asks each subclass component whether they should be used for that event scope. The Wicket implementations say yes if the wicket Application.exists() (which uses a ThreadLocal) returns true. The Faces implementations says yes if facesContext is not null. This patch assumes that both will not simultaneously return true, and if so, the behavior is undefined, as it's first-come-first-serve. If neither return true, the default Manager and StatusMessages implementation will be used. This happens during initialization and other edge cases where a manager is needed for event contexts that aren't tied to real requests. Note that since the FacesMessages component no longer has the same @Name as the StatusMessages component, it is now "org.jboss.seam.faces.facesMessages" which means the two factories for that name and its unqualified form in jboss-seam.jar's components.xml have been removed. (2) Seam's WicketFilter currently sets up scopes unconditionally if it is installed. This causes faces requests to fail because the SeamPhaseListener also sets up and tears down scopes, and so when the wicket filter finishes and tries to tear down its scopes, it finds them gone and an exception occurs. I've changed WicketFilter to not set up scopes, but instead to have WicketFilterInstantiator's anonymous subclass of the real WicketFilter install the scopes _if_ wicket has determined the request is a wicket request. (3) WicketExceptionFilter existed only to turn off the base ExceptionFilter for wicket classes. I've removed this class, and we'll need to add to the wicket seam documentation the need to map the ExceptionFilter in components.xml to jsf paths if wicket is to be used alongside jsf. (4) WicketRedirectFilter now co-exists with the base RedirectFilter, rather than replacing it. It checks to see if Wicket is active (via the same Application.exists() call as above) before doing any work to redirects, so that it doesn't duplicate work that the jsf RedirectFilter does. Likewise, The jsf RedirectFilter now checks to see if there is a faces context before doing any work. -- 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

15 years, 9 months

3
15
0 / 0

[jbossseam-issues] [JBoss JIRA] Created: (JBSEAM-3868) Automate seam-gen testing from the release-process.txt

by Jay Balunas (JIRA)

Automate seam-gen testing from the release-process.txt ------------------------------------------------------- Key: JBSEAM-3868 URL: https://jira.jboss.org/jira/browse/JBSEAM-3868 Project: Seam Issue Type: Task Components: Test Harness Affects Versions: 2.1.1.GA Reporter: Jay Balunas Assignee: Jay Balunas Priority: Critical Fix For: The future The release testing process outlined in release-process.txt for seam-gen needs to be automated. This will be a mixture of ant, selenium, etc.... -- 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

15 years, 9 months

2
4
0 / 0

2025

2024

2023

2022

2021

2020

2019

2018

2017

2016

2015

2014

2013

2012

2011

2010

2009

2008

2007

2006

seam-issues March 2009