[ http://jira.jboss.com/jira/browse/JBSEAM-2133?page=all ] Dan Allen updated JBSEAM-2133: ------------------------------ Attachment: JBSEAM-2133-v1.txt -- 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

[ http://jira.jboss.com/jira/browse/JBSEAM-2133?page=comments#action_12389718 ] Dan Allen commented on JBSEAM-2133: ----------------------------------- I did a thorough analysis and I can verify that this will only affect two of the examples and none of the test suites (meaning the suites will pass). However, it will be important to clarify this in the documentation. Here is why. Up until now, EL expressions in configuration properties have only been considered if the value of the property started with #{. Since most of the time the property value begins with #{ if it contains an expression at all, it appears as though the value expressions are always evaluated before assignment. You see an example of this used in the wiki example. <factory name="themePath" scope="APPLICATION" value="#{facesContext.externalContext.request.contextPath}/themes/#{wikiPreferences.themeName}"/> This would not have worked if it was instead written as <factory name="themePath" scope="APPLICATION" value="themes/#{wikiPreferences.themeName}"/> since it does not begin with #{. After adding this patch, you have to be aware that EL expressions are going to take affect during property assignment, even if they appear somewhere in the middle of the string. This happens a lot in query restrictions. <framework:entity-query name="artists" ejbql="select artist from Artist artist" order="artist.name DESC" max-results="5"> <framework:restrictions> <value>lower(artist.name) like lower(concat(#{exampleArtist.name}, '%'))</value> </framework:restrictions> </framework:entity-query> With this patch, it would have to be changed to this: <framework:entity-query name="artists" ejbql="select artist from Artist artist" order="artist.name DESC" max-results="5"> <framework:restrictions> <value>lower(artist.name) like lower(concat(\#{exampleArtist.name}, '%'))</value> </framework:restrictions> </framework:entity-query> Unfortunately this might cause breakage, but frankly I think the way it is right now is just inconsistent as hell. We need to go one way or the other, evaluate the expression or don't evaluate the expression. Right now we are sitting on the fence. -- 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

[ https://jira.jboss.org/jira/browse/JBSEAM-2133?page=com.atlassian.jira.pl... ] Dan Allen commented on JBSEAM-2133: ----------------------------------- Darn, I was hoping to get this in for Seam 2.1 where API changes would be expected. Feel free to open up a wider discussion. Perhaps we need to create a list of possible choices. -- 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

[ https://jira.jboss.org/jira/browse/JBSEAM-2133?page=com.atlassian.jira.pl... ] Dan Allen commented on JBSEAM-2133: ----------------------------------- I believe that I have a perfect solution for this problem. If the entire value is a single EL value expression, then we evaluate it when setting the bean property. We will call this a component reference (since that is the only way to refer to a component in the Seam component descriptor). If the value has mixed content, then it will not be evaluated before assigning to the property. This gives the developer the choice to evaluate it during the @Create method or at a later time. This is mostly how it works today, except that if the value starts with #{ we evaluate it, even if the content is mixed, so that is where the inconsistent behavior comes in. In an ideal world, we would always interpolate the value unless the target property's type is ValueExpression. However, if we make that change I fear we will break a lot of people's applications. We will also need to change the restrictions property on the Query component to be an array of ValueExpression objects instead of strings. -- 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

[ https://jira.jboss.org/jira/browse/JBSEAM-2133?page=com.atlassian.jira.pl... ] Dan Allen commented on JBSEAM-2133: ----------------------------------- I have made the decision to implement the following policy. If an initial value (a <property> in components.xml or a key in a seam.properties file) contains EL, it will be evaluated before being assigned to the bean property on the component, with on exception. If the property's type is a ValueExpression or MethodExpression (from the Seam library), then the evaluation will be deferred. You can either get the expression out using getExpressionString() or you can evaluate it when it is right for your application using getValue() (ValueExpression) or invoke() (MethodExpression). -- 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

[ https://jira.jboss.org/jira/browse/JBSEAM-2133?page=com.atlassian.jira.pl... ] Dan Allen resolved JBSEAM-2133. ------------------------------- Resolution: Done -- 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

[ https://jira.jboss.org/jira/browse/JBSEAM-2133?page=com.atlassian.jira.pl... ] Dan Allen commented on JBSEAM-2133: ----------------------------------- Uh oh! That commit came with a side of fries! Sorry about that, I will back that part out. I do still want to pursue that change, but that was supposed to be for a different commit and a different JIRA. -- 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