January 2010 - seam-issues - Jboss List Archives

[JBoss JIRA] Created: (JBSEAM-4509) EntityManager not injected on JBoss AS 6 M1

by Jozef Hartinger (JIRA)

EntityManager not injected on JBoss AS 6 M1 ------------------------------------------- Key: JBSEAM-4509 URL: https://jira.jboss.org/jira/browse/JBSEAM-4509 Project: Seam Issue Type: Bug Affects Versions: 2.2.0.GA Reporter: Jozef Hartinger Fix For: 2.2.1.CR1 In a certain circumstances, the following exception appears: To reproduce: 13:57:42,658 ERROR [[Faces Servlet]] Servlet.service() for servlet Faces Servlet threw exception org.jboss.seam.RequiredException: @In attribute requires non-null value: blog.entityManager at org.jboss.seam.Component.getValueToInject(Component.java:2335) at org.jboss.seam.Component.injectAttributes(Component.java:1736) at org.jboss.seam.Component.inject(Component.java:1554) at org.jboss.seam.core.BijectionInterceptor.aroundInvoke(BijectionInterceptor.java:61) at org.jboss.seam.intercept.SeamInvocationContext.proceed(SeamInvocationContext.java:68) at org.jboss.seam.core.MethodContextInterceptor.aroundInvoke(MethodContextInterceptor.java:44) at org.jboss.seam.intercept.SeamInvocationContext.proceed(SeamInvocationContext.java:68) at org.jboss.seam.intercept.RootInterceptor.invoke(RootInterceptor.java:107) at org.jboss.seam.intercept.JavaBeanInterceptor.interceptInvocation(JavaBeanInterceptor.java:185) at org.jboss.seam.intercept.JavaBeanInterceptor.invoke(JavaBeanInterceptor.java:103) at actions.BlogService_$$_javassist_seam_3.getBlog(BlogService_$$_javassist_seam_3.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 org.jboss.seam.util.Reflections.invoke(Reflections.java:22) at org.jboss.seam.util.Reflections.invokeAndWrap(Reflections.java:144) at org.jboss.seam.Component.callComponentMethod(Component.java:2249) at org.jboss.seam.Component.unwrap(Component.java:2275) at org.jboss.seam.Component.getInstance(Component.java:2041) at org.jboss.seam.Component.getInstance(Component.java:1983) at org.jboss.seam.Component.getInstance(Component.java:1977) 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:148) at org.jboss.seam.el.SeamELResolver.getValue(SeamELResolver.java:51) at javax.el.CompositeELResolver.getValue(CompositeELResolver.java:54) at com.sun.faces.el.FacesCompositeELResolver.getValue(FacesCompositeELResolver.java:72) 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.TagValueExpression.getValue(TagValueExpression.java:71) at javax.faces.component.ComponentStateHelper.eval(ComponentStateHelper.java:190) at javax.faces.component.ComponentStateHelper.eval(ComponentStateHelper.java:178) at javax.faces.component.UIData.getValue(UIData.java:554) at javax.faces.component.UIData.getDataModel(UIData.java:1243) at javax.faces.component.UIData.setRowIndex(UIData.java:447) at javax.faces.component.UIData.visitTree(UIData.java:1179) at javax.faces.component.UIComponent.visitTree(UIComponent.java:1454) at javax.faces.component.UIComponent.visitTree(UIComponent.java:1454) at javax.faces.component.UIViewRoot.processRestoreState(UIViewRoot.java:868) at com.sun.faces.application.StateManagerImpl.restoreView(StateManagerImpl.java:197) at org.jboss.seam.jsf.SeamStateManager.restoreView(SeamStateManager.java:76) at com.sun.faces.application.view.ViewHandlingStrategy.restoreView(ViewHandlingStrategy.java:131) at com.sun.faces.application.view.MultiViewHandler.restoreView(MultiViewHandler.java:143) at org.jboss.seam.jsf.SeamViewHandler.restoreView(SeamViewHandler.java:93) at com.sun.facelets.FaceletViewHandler.restoreView(FaceletViewHandler.java:316) at com.sun.faces.lifecycle.RestoreViewPhase.execute(RestoreViewPhase.java:199) at com.sun.faces.lifecycle.Phase.doPhase(Phase.java:101) at com.sun.faces.lifecycle.RestoreViewPhase.doPhase(RestoreViewPhase.java:110) at com.sun.faces.lifecycle.LifecycleImpl.execute(LifecycleImpl.java:118) at javax.faces.webapp.FacesServlet.service(FacesServlet.java:310) at org.apache.catalina.core.ApplicationFilterChain.internalDoFilter(ApplicationFilterChain.java:290) at org.apache.catalina.core.ApplicationFilterChain.doFilter(ApplicationFilterChain.java:206) at org.apache.catalina.core.ApplicationDispatcher.invoke(ApplicationDispatcher.java:638) at org.apache.catalina.core.ApplicationDispatcher.processRequest(ApplicationDispatcher.java:444) at org.apache.catalina.core.ApplicationDispatcher.doForward(ApplicationDispatcher.java:382) at org.apache.catalina.core.ApplicationDispatcher.forward(ApplicationDispatcher.java:310) at org.jboss.seam.web.RewriteFilter.process(RewriteFilter.java:98) at org.jboss.seam.web.RewriteFilter.doFilter(RewriteFilter.java:57) at org.jboss.seam.servlet.SeamFilter$FilterChainImpl.doFilter(SeamFilter.java:69) at org.jboss.seam.web.LoggingFilter.doFilter(LoggingFilter.java:60) at org.jboss.seam.servlet.SeamFilter$FilterChainImpl.doFilter(SeamFilter.java:69) at org.jboss.seam.web.IdentityFilter.doFilter(IdentityFilter.java:40) at org.jboss.seam.servlet.SeamFilter$FilterChainImpl.doFilter(SeamFilter.java:69) at org.jboss.seam.web.MultipartFilter.doFilter(MultipartFilter.java:90) 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.jboss.seam.web.HotDeployFilter.doFilter(HotDeployFilter.java:53) 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:235) at org.apache.catalina.core.StandardContextValve.invoke(StandardContextValve.java:191) at org.jboss.web.tomcat.security.SecurityAssociationValve.invoke(SecurityAssociationValve.java:183) at org.jboss.web.tomcat.security.JaccContextValve.invoke(JaccContextValve.java:95) at org.jboss.web.tomcat.security.SecurityContextEstablishmentValve.process(SecurityContextEstablishmentValve.java:126) at org.jboss.web.tomcat.security.SecurityContextEstablishmentValve.invoke(SecurityContextEstablishmentValve.java:70) 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:158) at org.apache.catalina.core.StandardEngineValve.invoke(StandardEngineValve.java:109) at org.apache.catalina.connector.CoyoteAdapter.service(CoyoteAdapter.java:330) at org.apache.coyote.http11.Http11Processor.process(Http11Processor.java:829) at org.apache.coyote.http11.Http11Protocol$Http11ConnectionHandler.process(Http11Protocol.java:598) at org.apache.tomcat.util.net.JIoEndpoint$Worker.run(JIoEndpoint.java:447) at java.lang.Thread.run(Thread.java:619) -- 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

16 years, 1 month

5
24
0 / 0

[jbossseam-issues] [JBoss JIRA] Created: (JBSEAM-4413) Date format error in .page.xml params when having custom date pattern

by Julien Kronegg (JIRA)

Date format error in .page.xml params when having custom date pattern --------------------------------------------------------------------- Key: JBSEAM-4413 URL: https://jira.jboss.org/jira/browse/JBSEAM-4413 Project: Seam Issue Type: Bug Affects Versions: 2.1.2.GA Environment: Seam 2.1.2.GA, DB2 http://fisheye.jboss.org/browse/Seam/branches/community/Seam_2_1/src/main... Reporter: Julien Kronegg Priority: Minor The java.util.Date passed by <param> tags in the .page.xml file are converted from Date to String for the GET request, using the date format defined in the last used rich:calendar. Then, the GET parameters are converted back from String to Date using the default date format which may not be the same as the one defined in the rich:calendar. This results in date conversion errors such as "value must be a date, eg. 10/13/2008". The issue is fully described with an example in http://seamframework.org/Community/DateFormatErrorInPagexmlParamsASeamIssue To correct this issue, the org.jboss.seam.navigation.Param should use its own date converter instead of sharing the converter with other JSF components (in other words, the Param class should use a technical date converter). This requires the following steps: 1) define a org.jboss.seam.faces.DateParamConverter date converter with a selectable date format defaulted to "yyyyMMddHHmmssSSS" 2) change the org.jboss.seam.navigation.Param class to use a the DateParamConverter converter if the param value is java.util.Date, else, use the converters registered in JSF. This is done by changing: Class<?> type = valueExpression.getType(); if (type==null) { return null; } return FacesContext.getCurrentInstance().getApplication().createConverter(type); by Class<?> type = valueExpression.getType(); if (type==null) { return null; } + if (type.equals(Date.class)) { + return org.jboss.seam.faces.DateParamConverter.getInstance(); // return an instance of the technical converter, to be created + } else { return FacesContext.getCurrentInstance().getApplication().createConverter(type); + } -- 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

16 years, 1 month

4
6
0 / 0

[jbossseam-issues] [JBoss JIRA] Created: (JBSEAM-4325) ResourceLoader, moving from JBoss 4 to JBoss 5, page level messages.properties not workin any more.

by Riccardo Serafin (JIRA)

ResourceLoader, moving from JBoss 4 to JBoss 5, page level messages.properties not workin any more. --------------------------------------------------------------------------------------------------- Key: JBSEAM-4325 URL: https://jira.jboss.org/jira/browse/JBSEAM-4325 Project: Seam Issue Type: Feature Request Components: Core, Documentation Issues Reporter: Riccardo Serafin Fix For: 2.2.1.CR1 We have moved our app from JBoss 4.2.3 to 5.1 and our page level messages.properties stopped to work correctly. After analyzing the issue, we traced the problem to the ResourceLoader loadBundle method which uses the getContextClassloader to load the bundles. In out app, the .properties files where located in the WAR root along with the faceltes .xhtml and the .page.xml, which use to work fine on 4.2.3. It is my understanding that with 5.1 the classloader has changed, and the one retrieved via getContextClassloader does not have access to the ServletContext anymore, hence our properties file are not found any more. So, I suggest two things: 1) The documentation makes it explicit that the messages.properties file should be localed in WEB-INF/classes. The explanation for the page level messages.properties is instead a bit more open to interpretation. It could be good to reiterate there that also page level files need to go into WEB-INF/classes 2) Or, modify ResourceLoader to scan also the ServletContext for bundle files, which would make it compatible with apps that used to work on JBoss 4.2.3. Notice that the other ResourceLoader methods already use ServletLifecycle.getServletContext(), that is why .page.xml files can be nicely placed along .xhtml file in the context root. Thanks, Riccardo. -- 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

16 years, 1 month

3
3
0 / 0

[jbossseam-issues] [JBoss JIRA] Created: (JBSEAM-4203) Interpolator swallows all exceptions

by Yuriy Lazarev (JIRA)

Interpolator swallows all exceptions ------------------------------------ Key: JBSEAM-4203 URL: https://jira.jboss.org/jira/browse/JBSEAM-4203 Project: Seam Issue Type: Bug Components: Core Affects Versions: 2.1.2.CR1 Environment: Any Reporter: Yuriy Lazarev org.jboss.seam.core.Interpolator swallows all exceptions, so if I have #{entityHome.instance.name} somewere in the page, and entityHome has id which is missed from database - I expect that org.jboss.seam.framework.EntityNotFoundException will be handled by this block in pages.xml <exception class = "org.jboss.seam.framework.EntityNotFoundException"> <redirect view-id = "/error.xhtml"> <message severity = "warn">#{messages['org.jboss.seam.framework.EntityNotFoundException']}</message> </redirect> </exception> but, instead I got [WARN] exception interpolating string: #{entityHome.instance.name} This is due Interpolator.java:131 } catch (Exception e) { log.warn("exception interpolating string: " + string, e); } -- 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

16 years, 1 month

4
5
0 / 0

[jbossseam-issues] [JBoss JIRA] Created: (JBSEAM-4462) Seam booking - outdated page footers

by Jozef Hartinger (JIRA)

Seam booking - outdated page footers ------------------------------------ Key: JBSEAM-4462 URL: https://jira.jboss.org/jira/browse/JBSEAM-4462 Project: Seam Issue Type: Bug Components: Examples Affects Versions: 2.2.0.GA Reporter: Jozef Hartinger Priority: Trivial Fix For: 2.2.1.CR1 Seam booking example and its derivates contain outdated page footers i.e. "Created with JBoss Seam 2.0, JBoss EJB 3.0, JSF 1.2, Hibernate 3 and Facelets" -- 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

16 years, 1 month

3
3
0 / 0

[JBoss JIRA] Created: (JBSEAM-4519) Conditional navigation rules vs JSF 2.0

by Stephan Bublava (JIRA)

Conditional navigation rules vs JSF 2.0 --------------------------------------- Key: JBSEAM-4519 URL: https://jira.jboss.org/jira/browse/JBSEAM-4519 Project: Seam Issue Type: Bug Components: JSF Integration Affects Versions: 2.2.0.GA Reporter: Stephan Bublava If the outcome of an action method is not covered by a navigation rule, you stay on the current page with JSF 1.2. With JSF 2.0 the outcome is interpreted as view id. Example: <page view-id="/administration/currency/edit-currency.html"> <navigation from-action="#{currencyEditor.confirmChanges}"> <rule if-outcome="confirm"> <render view-id="/administration/currency/confirm-edit-currency.html" /> </rule> </navigation> </page> If currencyEditor.confirmChanges() returns "edit", JSF 2.0 tries to render /administration/currency/edit.html instead of /administration/currency/edit-currency.html. BSEAM-4495 describes a similar problem. -- 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

16 years, 1 month

2
3
0 / 0

[jbossseam-issues] [JBoss JIRA] Created: (JBSEAM-4458) EL implementation doesn't coerce custom Number subclasses

by Johannes Rudolph (JIRA)

EL implementation doesn't coerce custom Number subclasses --------------------------------------------------------- Key: JBSEAM-4458 URL: https://jira.jboss.org/jira/browse/JBSEAM-4458 Project: Seam Issue Type: Bug Components: EL Affects Versions: 2.1.2.GA Reporter: Johannes Rudolph Priority: Minor The title says it all. Here's the Bug-Report in the apache bug tracker. It seems the JBoss-EL implementation was directly copied from there: https://issues.apache.org/bugzilla/show_bug.cgi?id=44766 The problem lies in ELArithmetic.isNumberType which - in the version integrated into JBoss EL - uses a stupid way to determine if an object is a Number. -- 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

16 years, 1 month

1
1
0 / 0

[jbossseam-issues] [JBoss JIRA] Created: (JBSEAM-4141) Page <restrict> tag, Ajax call and POST parameters

by Jarek Gilewski (JIRA)

Page <restrict> tag, Ajax call and POST parameters -------------------------------------------------- Key: JBSEAM-4141 URL: https://jira.jboss.org/jira/browse/JBSEAM-4141 Project: Seam Issue Type: Bug Components: Security Affects Versions: 2.1.1.GA Reporter: Jarek Gilewski Priority: Blocker The problem is that <restrict> part is always trigered before the page parameters are properly set with Ajax/POST call on the page. -- 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

16 years, 1 month

2
1
0 / 0

[jbossseam-issues] [JBoss JIRA] Created: (JBSEAM-4424) Current identity store incorrectly detected by JpaPermissionStore if identity store extends JpaIdentityStoreClass

by Alexander Galanin (JIRA)

Current identity store incorrectly detected by JpaPermissionStore if identity store extends JpaIdentityStoreClass ----------------------------------------------------------------------------------------------------------------- Key: JBSEAM-4424 URL: https://jira.jboss.org/jira/browse/JBSEAM-4424 Project: Seam Issue Type: Bug Components: Security Affects Versions: 2.2.0.GA Reporter: Alexander Galanin Priority: Minor Current identity store incorrectly detected by JpaPermissionStore if identity store extends JpaIdentityStoreClass. The following line in function resolvePrincipalEntity() (class JpaPermissionStore) is incorrect in my case: JpaIdentityStore identityStore = (JpaIdentityStore) Component.getInstance(JpaIdentityStore.class, true); Should be (copy-pasted from resolvePrincipal()) IdentityStore ids = IdentityManager.instance().getRoleIdentityStore(); JpaIdentityStore identityStore = null; if (ids instanceof JpaIdentityStore) { identityStore = (JpaIdentityStore) ids; } -- 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

16 years, 1 month

2
1
0 / 0

[jbossseam-issues] [JBoss JIRA] Created: (JBSEAM-2766) Enable Security for POJO WebServices Endpoint

by Srinivasan Raguraman (JIRA)

Enable Security for POJO WebServices Endpoint --------------------------------------------- Key: JBSEAM-2766 URL: http://jira.jboss.com/jira/browse/JBSEAM-2766 Project: JBoss Seam Issue Type: Feature Request Components: Security, WS Affects Versions: 2.0.0.GA Environment: JBoss 4.2.1GA Reporter: Srinivasan Raguraman The @Restrict annotation on Seam component are never applied if they were exposed directly as web service end-point. This is probably because the y are not initialized as seam components, by the web service layer. Right now the workaround is to have facade layer over seam components and expose them as web service end-point. The security interceptor on POJO components could be enabled by AOP interception or by some other delegation. -- 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, 1 month

2
2
0 / 0

2026

2025

2024

2023

2022

2021

2020

2019

2018

2017

2016

2015

2014

2013

2012

2011

2010

2009

2008

2007

2006

seam-issues January 2010