[jbossseam-issues] [JBoss JIRA] Created: (JBSEAM-1254) facesmessages are not always fully interpolated
by Keith Naas (JIRA)
facesmessages are not always fully interpolated
-----------------------------------------------
Key: JBSEAM-1254
URL: http://jira.jboss.com/jira/browse/JBSEAM-1254
Project: JBoss Seam
Issue Type: Feature Request
Components: JSF
Affects Versions: 1.2.1.GA
Reporter: Keith Naas
Priority: Minor
Whenever "FacesMessages.createFacesMessage(Severity severity, String messageTemplate, Object... params)" is called, the message is fully interpolated. Meaning, it will resolve EL expressions inside of the message itself. When "FacesMessages.createFacesMessage(Severity severity, String key, String defaultMessageTemplate, Object... params)", it does not do this full EL expression resolution. The code changes below would probably support this.
private static String interpolateBundleMessage(String key, String defaultMessageTemplate, Object... params)
{
String messageTemplate = defaultMessageTemplate;
if ( key!=null )
{
java.util.ResourceBundle resourceBundle = ResourceBundle.instance();
if ( resourceBundle!=null )
{
try
{
String bundleMessage = resourceBundle.getString(key);
if (bundleMessage!=null) messageTemplate = bundleMessage;
}
catch (MissingResourceException mre) {} //swallow
}
}
return Interpolator.instance().interpolate(messageTemplate, params);
}
public static FacesMessage createFacesMessage(Severity severity, String key, String defaultMessageTemplate, Object... params)
{
String message = interpolateBundleMessage(key, defaultMessageTemplate, params);
if ( !Strings.isEmpty(message) )
{
return createFacesMessage( severity, message, null);
}
else
{
return null;
}
}
--
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-1253) jboss-el resolver chain breaks on HashMap$Value
by Stuart Robertson (JIRA)
jboss-el resolver chain breaks on HashMap$Value
-----------------------------------------------
Key: JBSEAM-1253
URL: http://jira.jboss.com/jira/browse/JBSEAM-1253
Project: JBoss Seam
Issue Type: Bug
Components: JSF
Affects Versions: 1.2.1.GA
Environment: Seam from CVS, JBoss 4.2.0CR2, Facelets
Reporter: Stuart Robertson
HashMap$Value extends AbstractCollection, so I expected the following to work. I'm creating a unordered list from the values in a Map. Here's the xhtml:
<ui:repeat var="descriptor" value="#{catalogMapping.rawApplicableDescriptors.conditionalRequired}">
<h:outputText value="#{descriptor.description}"/>
</ui:repeat>
Here's the relevant bits in "rawApplicableDescriptors":
private final Map<String, CatalogItemDescriptor> conditionalRequired = new HashMap<String, CatalogItemDescriptor>();
public Collection<CatalogItemDescriptor> getConditionalRequired()
{
return conditionalRequired.values();
}
But here's what I see:
Caused by: javax.el.PropertyNotFoundException: /members/catalog/mapping/applicable-fields.xhtml @20,54 value="#{descriptor.description}": Property 'description' not found on type java.util.HashMap$Values
at com.sun.facelets.el.TagValueExpression.getValue(TagValueExpression.java:73)
at javax.faces.component.UIOutput.getValue(UIOutput.java:173)
Tracing through in the debugger, all of the resolvers in the chain are called in sequence, and none of them can resolve the value. It appears the one that is throwing (Wish I knew why Eclipse isn't showing the inner stacktrace) is BeanElResolver, from jboss-el. Looks like NullPointer at:
public Object getValue(ELContext context, Object base, Object property)
throws NullPointerException, PropertyNotFoundException, ELException {
if (context == null) {
throw new NullPointerException();
}
Hmm. Wait. Duh. The problem is't down here. It's in the el's handling of
value="#{catalogMapping.rawApplicableDescriptors.conditionalRequired}".
ui:repeat should be iterating over the contents of the collection. Meaning #{descriptor...} should be an instance of the contained type. Instead <h:outputText value="#{descriptor.description}"/> is trying to resolve "description" as a property of the _collection itself_.
I'm having trouble giving more detail on this one. It should be very easy to reproduce. Please let me know if there's anything I can do to help investigate.
Oh, and this works fine if I iterate over a list rather than a collection of type HashMap$Value
--
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-1252) SeamTest invokeMethod() breaks jboss-el: "Parameter types cannot be null"
by Stuart Robertson (JIRA)
SeamTest invokeMethod() breaks jboss-el: "Parameter types cannot be null"
-------------------------------------------------------------------------
Key: JBSEAM-1252
URL: http://jira.jboss.com/jira/browse/JBSEAM-1252
Project: JBoss Seam
Issue Type: Bug
Components: Core
Affects Versions: 1.2.1.GA
Environment: Seam from CVS. Jboss 4.2.0CR2. Facelets and JSF RI
Reporter: Stuart Robertson
Priority: Minor
SeamTest and MockApplication pass null as parameters to the MethodBinding. Jboss-el throws if they are null, and expects a zero sized array.
Here's an example of what breaks it:
invokeMethod("#{register.register}");
Here's the exception thrown:
FAILED: registerTest
java.lang.NullPointerException: Parameter types cannot be null
at org.jboss.el.ExpressionFactoryImpl.createMethodExpression(ExpressionFactoryImpl.java:53)
at org.jboss.seam.util.UnifiedELMethodBinding.<init>(UnifiedELMethodBinding.java:18)
at org.jboss.seam.mock.MockApplication.createMethodBinding(MockApplication.java:270)
at org.jboss.seam.jsf.SeamApplication.createMethodBinding(SeamApplication.java:291)
at org.jboss.seam.mock.SeamTest$Request.invokeMethod(SeamTest.java:400)
at com.fb.core.test.catalog.RegisterAndLoginTest$RegisterFacesRequest.invokeApplication(RegisterAndLoginTest.java:254)
at org.jboss.seam.mock.SeamTest$Request.run(SeamTest.java:488)
at com.fb.core.test.catalog.RegisterAndLoginTest.registerTest(RegisterAndLoginTest.java:55)
Here's a patch that made the test run successfully:
### Eclipse Workspace Patch 1.0
#P jboss-seam
Index: src/main/org/jboss/seam/mock/SeamTest.java
===================================================================
RCS file: /cvsroot/jboss/jboss-seam/src/main/org/jboss/seam/mock/SeamTest.java,v
retrieving revision 1.66
diff -u -r1.66 SeamTest.java
--- src/main/org/jboss/seam/mock/SeamTest.java 24 Apr 2007 02:32:58 -0000 1.66
+++ src/main/org/jboss/seam/mock/SeamTest.java 26 Apr 2007 12:16:10 -0000
@@ -397,7 +397,7 @@
*/
protected Object invokeMethod(String methodExpression)
{
- return application.createMethodBinding(methodExpression, null).invoke(facesContext, null);
+ return application.createMethodBinding(methodExpression, new Class [0]).invoke(facesContext, null);
}
/**
Though SeamTest would still not accept method expression parameters with this change.
--
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-1264) Session preDestroyContext Event causing exception
by Keith Naas (JIRA)
Session preDestroyContext Event causing exception
-------------------------------------------------
Key: JBSEAM-1264
URL: http://jira.jboss.com/jira/browse/JBSEAM-1264
Project: JBoss Seam
Issue Type: Bug
Affects Versions: 1.2.1.GA
Reporter: Keith Naas
Priority: Minor
This is probably the wrong thing to do for what we need...but we did encounter this interesting error.
We registered an event on the preDestroyContext.SESSION where a stateless EJB is called to delete some items from a database.
<event type="org.jboss.seam.preDestroyContext.SESSION">
<action expression="#{service.releaseDocuments}"/>
</event>
When EJBs are passivated, this event appears to be kicking off. But since the FacesContext is null, we get a NullPointerException from com.sun.faces.application.MethodBindingMethodExpressionAdapter.invoke.
It looks like the FaceContext is null when it is called through the passivate interceptor, but it is calling the previous cachedMethodBinding which was generated when the FaceContext was not null.
Seems like the method should be changed to something like this.
private javax.faces.el.MethodBinding getFacesMethodBinding(Class[] types, Object... args)
{
FacesContext context = FacesContext.getCurrentInstance();
if (cachedMethodBinding==null || (context == null && !(cachedMethodBinding instanceof UnifiedELMethodBinding)))
{
cachedMethodBinding = context==null ?
new UnifiedELMethodBinding(expression, types) :
context.getApplication().createMethodBinding(expression, types);
}
return cachedMethodBinding;
}
11:54:08,526 ERROR [SimpleStatefulCache] problem passivation thread
java.lang.RuntimeException: java.lang.NullPointerException: FacesConext -> null
at org.jboss.ejb3.interceptor.LifecycleInterceptorHandler.prePassivate(LifecycleInterceptorHandler.java:160)
at org.jboss.ejb3.stateful.StatefulContainer.invokePrePassivate(StatefulContainer.java:351)
at org.jboss.ejb3.stateful.StatefulBeanContext.prePassivate(StatefulBeanContext.java:178)
at org.jboss.ejb3.cache.simple.StatefulSessionFilePersistenceManager.passivateSession(StatefulSessionFilePersistenceManager.java:328)
at org.jboss.ejb3.cache.simple.SimpleStatefulCache.passivate(SimpleStatefulCache.java:194)
at org.jboss.ejb3.cache.simple.SimpleStatefulCache$SessionTimeoutTask.run(SimpleStatefulCache.java:129)
Caused by: java.lang.NullPointerException: FacesConext -> null
at com.sun.faces.application.MethodBindingMethodExpressionAdapter.invoke(MethodBindingMethodExpressionAdapter.java:72)
at org.jboss.seam.core.Expressions$2.invoke(Expressions.java:148)
at org.jboss.seam.core.Events.raiseEvent(Events.java:63)
at org.jboss.seam.contexts.Contexts.destroy(Contexts.java:215)
at org.jboss.seam.contexts.Lifecycle.endCall(Lifecycle.java:72)
at org.jboss.seam.intercept.RootInterceptor.invoke(RootInterceptor.java:117)
at org.jboss.seam.intercept.RootInterceptor.invokeAndHandle(RootInterceptor.java:81)
at org.jboss.seam.intercept.SessionBeanInterceptor.prePassivate(SessionBeanInterceptor.java:59)
at sun.reflect.GeneratedMethodAccessor1059.invoke(Unknown Source)
at sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:25)
at java.lang.reflect.Method.invoke(Method.java:585)
at org.jboss.ejb3.interceptor.LifecycleInvocationContextImpl.proceed(LifecycleInvocationContextImpl.java:131)
at org.jboss.ejb3.interceptor.LifecycleInterceptorHandler.prePassivate(LifecycleInterceptorHandler.java:156)
... 5 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-1225) JBoss EL has issues with boolean expressions
by Christian Bauer (JIRA)
JBoss EL has issues with boolean expressions
--------------------------------------------
Key: JBSEAM-1225
URL: http://jira.jboss.com/jira/browse/JBSEAM-1225
Project: JBoss Seam
Issue Type: Bug
Components: Core
Reporter: Christian Bauer
Priority: Minor
Not sure this is critical and in fact, not even sure that this is supposed to work. I wrote this rather stupid expression which JBoss EL doesn't like:
<s:div rendered="#{s:hasPermission('User', 'isAdmin', currentUser)
and not userHome.instance.id == adminUser.id
and not userHome.instance.id == guestUser.id}">
The exception is rather strange:
java.lang.NoClassDefFoundError
org.jboss.el.lang.ELSupport.coerceToBoolean(ELSupport.java:177)
org.jboss.el.parser.AstNot.getValue(AstNot.java:27)
org.jboss.el.parser.AstEqual.getValue(AstEqual.java:21)
org.jboss.el.parser.AstAnd.getValue(AstAnd.java:26)
org.jboss.el.parser.AstAnd.getValue(AstAnd.java:21)
org.jboss.el.ValueExpressionImpl.getValue(ValueExpressionImpl.java:186)
com.sun.facelets.el.TagValueExpression.getValue(TagValueExpression.java:71)
javax.faces.component.UIComponentBase.isRendered(UIComponentBase.java:370)
org.ajax4jsf.framework.renderer.RendererBase.renderChild(RendererBase.java:276)
org.ajax4jsf.framework.renderer.RendererBase.renderChildren(RendererBase.java:262)
org.ajax4jsf.framework.renderer.RendererBase.renderChild(RendererBase.java:284)
org.ajax4jsf.framework.renderer.RendererBase.renderChildren(RendererBase.java:262)
org.richfaces.renderkit.html.PanelBarItemRenderer.doEncodeChildren(PanelBarItemRenderer.java:136)
org.richfaces.renderkit.html.PanelBarItemRenderer.doEncodeChildren(PanelBarItemRenderer.java:131)
org.ajax4jsf.framework.renderer.RendererBase.encodeChildren(RendererBase.java:121)
javax.faces.component.UIComponentBase.encodeChildren(UIComponentBase.java:809)
org.ajax4jsf.framework.renderer.RendererBase.renderChild(RendererBase.java:282)
org.ajax4jsf.framework.renderer.RendererBase.renderChildren(RendererBase.java:262)
org.richfaces.renderkit.html.PanelBarRenderer.doEncodeChildren(PanelBarRenderer.java:148)
org.richfaces.renderkit.html.PanelBarRenderer.doEncodeChildren(PanelBarRenderer.java:143)
org.ajax4jsf.framework.renderer.RendererBase.encodeChildren(RendererBase.java:121)
javax.faces.component.UIComponentBase.encodeChildren(UIComponentBase.java:809)
javax.faces.component.UIComponent.encodeAll(UIComponent.java:886)
javax.faces.render.Renderer.encodeChildren(Renderer.java:137)
javax.faces.component.UIComponentBase.encodeChildren(UIComponentBase.java:809)
javax.faces.component.UIComponent.encodeAll(UIComponent.java:886)
javax.faces.component.UIComponent.encodeAll(UIComponent.java:892)
javax.faces.component.UIComponent.encodeAll(UIComponent.java:892)
javax.faces.component.UIComponent.encodeAll(UIComponent.java:892)
com.sun.facelets.FaceletViewHandler.renderView(FaceletViewHandler.java:571)
org.ajax4jsf.framework.ViewHandlerWrapper.renderView(ViewHandlerWrapper.java:108)
org.ajax4jsf.framework.ajax.AjaxViewHandler.renderView(AjaxViewHandler.java:229)
com.sun.faces.lifecycle.RenderResponsePhase.execute(RenderResponsePhase.java:106)
com.sun.faces.lifecycle.LifecycleImpl.phase(LifecycleImpl.java:251)
com.sun.faces.lifecycle.LifecycleImpl.render(LifecycleImpl.java:144)
javax.faces.webapp.FacesServlet.service(FacesServlet.java:245)
org.tuckey.web.filters.urlrewrite.RuleChain.handleRewrite(RuleChain.java:164)
org.tuckey.web.filters.urlrewrite.RuleChain.doRules(RuleChain.java:141)
org.tuckey.web.filters.urlrewrite.UrlRewriter.processRequest(UrlRewriter.java:90)
org.tuckey.web.filters.urlrewrite.UrlRewriteFilter.doFilter(UrlRewriteFilter.java:395)
org.jboss.seam.web.SeamFilter$FilterChainImpl.doFilter(SeamFilter.java:63)
org.jboss.seam.web.SeamFilter$FilterChainImpl.doFilter(SeamFilter.java:53)
org.jboss.seam.web.ExceptionFilter.doFilter(ExceptionFilter.java:57)
org.jboss.seam.web.SeamFilter$FilterChainImpl.doFilter(SeamFilter.java:49)
org.jboss.seam.web.MultipartFilter.doFilter(MultipartFilter.java:79)
org.jboss.seam.web.SeamFilter$FilterChainImpl.doFilter(SeamFilter.java:49)
org.jboss.seam.web.RedirectFilter.doFilter(RedirectFilter.java:45)
org.jboss.seam.web.SeamFilter$FilterChainImpl.doFilter(SeamFilter.java:49)
org.jboss.seam.web.SeamFilter.doFilter(SeamFilter.java:84)
org.ajax4jsf.framework.ajax.xmlfilter.BaseXMLFilter.doXmlFilter(BaseXMLFilter.java:96)
org.ajax4jsf.framework.ajax.xmlfilter.BaseFilter.doFilter(BaseFilter.java:220)
org.jboss.web.tomcat.filters.ReplyHeaderFilter.doFilter(ReplyHeaderFilter.java:96)
--
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-1215) <s:convertEntity> / org.jboss.seam.ui.EntityConverter fails to return correct id when entity is wrapped Hibernate proxy (JavassistLazyInitializer)
by Kahli Burke (JIRA)
<s:convertEntity> / org.jboss.seam.ui.EntityConverter fails to return correct id when entity is wrapped Hibernate proxy (JavassistLazyInitializer)
--------------------------------------------------------------------------------------------------------------------------------------------------
Key: JBSEAM-1215
URL: http://jira.jboss.com/jira/browse/JBSEAM-1215
Project: JBoss Seam
Issue Type: Bug
Components: JSF
Affects Versions: 1.2.1.GA
Environment: JBoss Seam 1.2.1, JBoss 4.0.5GA, Hibernate 3.2.1, JSF RI 1.2, Facelets 1.1.12
Reporter: Kahli Burke
In certain circumstances the <s:entityConverter> handler org.jboss.seam.ui.EntityConverter will fail to return the correct id for the entity when getAsString() is called. I have seen this occur when one of my components called entityManager.clear(), and then on a subsequence page load a query was made. In this case, the actual object used in getIdFromEntity() was a proxied object. The object was proxied by Hibernate's JavassistLazyInitializer.
The getIdFromEntity() method looks for a field annotated with @Id, which this entity has (we are using field annotations as opposed to method annotations), and then attempts to get the id from the object using direct field access (through Reflections.get(field, entity)). Because the object is wrapped, this returns the default value for the class. In my case it returns 0 for the id since this entity uses a long for the id field.
If the getter method had been called instead, the correct non-zero value would have been returned. And usually, this works because the object is an actual instance of the entity class and has the correct value for the field.
My workaround for now is to create a subclass of EntityConverter (and using the very useful @Install precedence, thank you!) that calls the superclass' implementation and in cases where it looks like it might be incorrect, looks for a getter method and calls that instead. There is probably a better way to do it, but I'm not familiar with the Hibernate proxies or how to properly get at the underlying object.
@Override
protected Object getIdFromEntity(UIComponent cmp, FacesContext facesContext, Object entity, Class entityClass) {
Object id = super.getIdFromEntity(cmp, facesContext, entity, entityClass);
// If the id looks like it came out incorrect from the field access
if ((id instanceof Number && ((Number) id).longValue() == 0) || (id == null)) {
List<Field> fields = Reflections.getFields(entityClass, Id.class);
if (fields.size() == 1) {
Field field = fields.get(0);
Method getter = null;
try {
getter = Reflections.getGetterMethod(entityClass, field.getName());
}
catch (IllegalArgumentException e) {
if (log.isDebugEnabled())
log.debug("Id #0 looked incorrect, but unable to find getter method for field #1", id, field.getName());
return id;
}
if (getter != null) {
try {
id = Reflections.invoke(getter, entity);
}
catch (Exception e) {
log.error("Error invoking getter method #0, returning original id #1", e, getter.getName(), id);
}
}
}
}
return id;
}
--
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