[jbossseam-issues] [JBoss JIRA] Created: (JBSEAM-2050) reorganize modules
by Dan Allen (JIRA)
reorganize modules
------------------
Key: JBSEAM-2050
URL: http://jira.jboss.com/jira/browse/JBSEAM-2050
Project: JBoss Seam
Issue Type: Feature Request
Components: Tools
Affects Versions: 2.0.0.CR1
Reporter: Dan Allen
Fix For: 2.0.x
I would like to make "modules" a first order directory (renamed from "src") and also organize tests so they are per-module. This will encourage per-module tests and also prevent circular dependencies (because the folders are treated as modules and not one big lump of source code). The ui module also once again finds itself adjacent to the other modules.
jboss-seam/
examples/ <-- showing this just as a reference point
modules/
core/
main/java
test/java
ui/
main/java
test/java
(continue for debug, ioc, gen, pdf, mail, remoting)
Although Eclipse doesn't know the first think about multi-modules, this will be idea for setting up a module-aware IDE like IntelliJ IDEA (and to some degree, NetBeans).
--
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
14 years, 10 months
[jbossseam-issues] [JBoss JIRA] Created: (JBSEAM-1710) Support multiple life cycle methods (per inheritance) on JavaBean classes
by Dan Allen (JIRA)
Support multiple life cycle methods (per inheritance) on JavaBean classes
-------------------------------------------------------------------------
Key: JBSEAM-1710
URL: http://jira.jboss.com/jira/browse/JBSEAM-1710
Project: JBoss Seam
Issue Type: Bug
Components: Core
Affects Versions: 2.0.0.BETA1, 2.0.0.CR1
Reporter: Dan Allen
Priority: Minor
EJB supports multiple life cycle methods for a bean, as long as two life cycle methods do not appear in the same class in the inheritance hierarchy. Thus, you can define a @PostConstruct method on the concrete class, and a different @PostConstruct method on its superclass.
As per the EJB specification (with minor corrections for clarity):
"Life cycle callback interceptor methods may be defined on super classes of the bean class, the bean class itself, or interceptor classes. However, a given class may not have more than one life cycle callback interceptor method for the same life cycle event."
The following comment is found in Component.java regarding this issue:
// TODO: check the EJB3 spec, I think you are allowed to have multiple life cycle methods on a bean!
The comment is correct in that multiple life cycle methods are not allowed on a single bean class. However, through inheritance, it is possible to have two different life cycle methods for the same Seam component.
Currently, Component#initMembers() works backwards up the inheritance chain while scanning methods. Therefore, the life cycle method on the highest member of the hierarchy currently wins. So, as it stands now, the handling of life cycle callbacks for JavaBeans is inconsistent with how they are handled by the EJB container on session and message-driven beans. I was able to verify this with a simple demonstration I conducted.
This incompatibility shouldn't be too difficult to fix. Just switch the life cycle method properties to an array and ensure that superclass methods are called first.
--
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
14 years, 10 months
[jbossseam-issues] [JBoss JIRA] Created: (JBSEAM-1670) allow multiple scopes for @In annotation
by Dan Allen (JIRA)
allow multiple scopes for @In annotation
----------------------------------------
Key: JBSEAM-1670
URL: http://jira.jboss.com/jira/browse/JBSEAM-1670
Project: JBoss Seam
Issue Type: Patch
Components: Core
Affects Versions: 2.0.0.BETA1
Reporter: Dan Allen
Priority: Minor
Fix For: 2.0.0.CR1, 2.0.0.GA, 2.0.1.GA
Right now, your only option for the scope on the @In annotation is an explicit scope or a hierarchical search of all the scopes. I can imagine that there are times when you want to look in a handful of scopes, but not all of them. For instance, anything within a conversation, but not above. Additionally, by making this a multi-value attribute, the developer can override the order in which the scopes are searched. They are searched in the order specified.
ScopeType[] scope() default {};
This would also eliminate the need for the UNSPECIFIED scope since no scopes would assume a hierarchical search. The logic that would have to change is Component#getValueToInject()
--
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
14 years, 10 months
[jbossseam-issues] [JBoss JIRA] Created: (JBSEAM-1389) Please make the methods parse and createPage protected instead of private.
by Chris Rudd (JIRA)
Please make the methods parse and createPage protected instead of private.
--------------------------------------------------------------------------
Key: JBSEAM-1389
URL: http://jira.jboss.com/jira/browse/JBSEAM-1389
Project: JBoss Seam
Issue Type: Feature Request
Components: Core
Reporter: Chris Rudd
We have a dynamic routine that locates pages xml files from multiple locations. Since parse and createPage are private methods we cannot override and extend the Pages component without lifting the entire source and replicating it, or using reflection to get at those methods. Neither of these are good long term aproaches.
In general it seems that lots of the core components that one might want to extend to hook in additional functionality cannot be due to the use of private instead of protected methods.
The extended funtionality provided by the resolution to JBSEAM-715 does not rectify my issue as that relies on explitly defining the pages xml files. I believe there are several other people who are looking for a way to use an algorithm to locate them rather than a fixed list. Making those methods protected solves the problem as it allows anyone to extend the functionaliry of the Pages component to provide extended rules / algorithms for locating pages xml files, while not affecting the functionality of the core at all.
--
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
14 years, 10 months
[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
14 years, 10 months
[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
14 years, 10 months
[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
14 years, 10 months
