Re: ext-bv addon: Required Initialization for labels required change
Ben,
Nice to hear it worked. also good to know that it works with you combine
them. Didn't try that yet. Thx for the info.
regards
Rudy.
On 27 October 2010 17:22, neum...@ijet.com wrote:
Rudy,
FYI, I am using both the bean-val and property versions together
successfully (I reverted my change to the bean-val version).
Thanks!
Ben
ps. It was necessary to make a change in the property version to account
for a NullPointerException. I'll start a new thread for that.
-Ben
-Original Message-
*From:* neum...@ijet.com [mailto:neum...@ijet.com]
*Sent:* Wednesday, October 27, 2010 10:31 AM
*To:* dev@myfaces.apache.org
*Subject:* RE: ext-bv addon: Required Initialization for labels required
change
Rudy,
--But commenting out the super.initComponent as you proposed will
result in not recognizing the Bean validation annoations anymore.--
Thanks for the info. I'm sure I'll need both property *and* bean
annotations on some properties.
I'll try using both versions together.
Ben
-Original Message-
*From:* Rudy De Busscher [mailto:rdebussc...@gmail.com]
*Sent:* Wednesday, October 27, 2010 10:19 AM
*To:* MyFaces Development
*Subject:* Re: ext-bv addon: Required Initialization for labels required
change
Ben,
There exists 2 version because the handling of Bean Validation annotations
is completely different then the 'standard' ones (you are using JPA
annotations but there exists also ExtVal annotations like @Required that do
more or less the same as the Bean Validation annotations)
The issue that you have now is that the Required Label add-on (BV version)
is not recognizing the NON Bean validation annotations.
I'll have a look now that I know more of the context.
Did you add only the bean-validation module to the project or also
property-validation module ?
But commenting out the super.initComponent as you proposed will result in
not recognizing the Bean validation annoations anymore.
Rudy.
On 27 October 2010 16:09, neum...@ijet.com wrote:
Rudy,
I haven't tried the non-bean version yet but was just wondering if this is
the only difference between the two versions?
If so, why not just make one version that applies the correct component
init/config method based on the annotation type (bean vs property)?
Ben
-Original Message-
*From:* neum...@ijet.com [mailto:neum...@ijet.com]
*Sent:* Wednesday, October 27, 2010 9:40 AM
*To:* dev@myfaces.apache.org
*Subject:* RE: ext-bv addon: Required Initialization for labels required
change
Hi Rudy,
I am using both property and bean validation. The labels of concern,
though, are annotated using @Column(...nullable=false). So perhaps we've
discovered my issue. Thanks!
I will drop in the non-bean validation version and see how that works.
Is there any reason why I can't/shouldn't use both?
Finally, the target component is standard JSF.
Thanks!
Ben
-Original Message-
*From:* Rudy De Busscher [mailto:rdebussc...@gmail.com]
*Sent:* Wednesday, October 27, 2010 8:40 AM
*To:* MyFaces Development
*Subject:* Re: ext-bv addon: Required Initialization for labels required
change
Hello Ben,
I made a few checks and within my examples everything works (they don't
use Richfaces however). Can it be that you are mixing some environments ??
The line of code
*ExtValUtils.**configureComponentWithMetaData**(facesContext,
targetComponent, ExtValUtils.**getTransformedMetaData(**facesContext,
targetComponent));*
is typical for the usage WITHOUT bean validation.
Are you using bean validation annotations (like
javax.validation.constraints.NotNull) on your properties?
If not, there exists also an add-on for the non bean validation version.
Is the target component a richfaces faces component or a standard JSF one
??
I try to check with a RichFaces component tomorrow.
regards
Rudy.
On 26 October 2010 22:32, Gerhard gerhard.petra...@gmail.com wrote:
hi ben,
thx for the information - we will check it!
(we haven't released the add-on - so we have to do some final tests.)
@rudy:
it would be nice if you can check the change with your applications.
regards,
gerhard
http://www.irian.at
Your JSF powerhouse -
JSF Consulting, Development and
Courses in English and German
Professional Support for Apache MyFaces
2010/10/26 neum...@ijet.com
Just a short note that may be of interest.
I was unable to get the ext-bv addon: Required Initialization for labels
working out of the box.
After modifying
at.gp.web.jsf.extval.beanval.label.interceptor.BeanValidationAwareLabelRendererInterceptor
as follows, it seems to work well now.
protected void initComponent(FacesContext facesContext, UIComponent
uiComponent)
{
...
//super.initComponent(facesContext, targetComponent);
ExtValUtils.configureComponentWithMetaData(facesContext,
targetComponent, ExtValUtils.getTransformedMetaData(facesContext,
targetComponent));
Re: JBoss and MyFaces ....
In Tomcat I also see this, using 2.0.2: points to StartupFacesContextImpl and to RuntimeConfig as well .10.2010 15:37:54 org.apache.catalina.loader.WebappClassLoader clearThreadLocalMap SCHWERWIEGEND: The web application [/webprofile] created a ThreadLocal with key of type [java.lang.ThreadLocal] (value [java.lang.threadlo...@203822fc]) and a value of type [org.apache.myfaces.context.servlet.StartupFacesContextImpl] (value [org.apache.myfaces.context.servlet.startupfacescontexti...@4580deea]) but failed to remove it when the web application was stopped. This is very likely to create a memory leak. 27.10.2010 15:37:54 org.apache.catalina.loader.WebappClassLoader clearThreadLocalMap SCHWERWIEGEND: The web application [/webprofile] created a ThreadLocal with key of type [java.lang.ThreadLocal] (value [java.lang.threadlo...@faaf84c]) and a value of type [org.apache.myfaces.context.servlet.StartupFacesContextImpl] (value [org.apache.myfaces.context.servlet.startupfacescontexti...@21934d9d]) but failed to remove it when the web application was stopped. This is very likely to create a memory leak. 27.10.2010 15:37:54 org.apache.catalina.loader.WebappClassLoader clearThreadLocalMap SCHWERWIEGEND: The web application [/webprofile] created a ThreadLocal with key of type [java.lang.ThreadLocal] (value [java.lang.threadlo...@4dcc8fa3]) and a value of type [org.apache.myfaces.config.RuntimeConfig] (value [org.apache.myfaces.config.runtimecon...@30ea3e3c]) but failed to remove it when the web application was stopped. This is very likely to create a memory leak. .Matthias On Fri, Oct 15, 2010 at 2:36 PM, ssilv...@redhat.com wrote: Quoting Bruno Aranda brunoara...@gmail.com: Using tomcat 7 I get this warning... SEVERE: The web application [/editor-2.0-SNAPSHOT] created a ThreadLocal with key of type [java.lang.ThreadLocal] (value [java.lang.threadlo...@41649a55]) and a value of type [org.apache.myfaces.config.RuntimeConfig] (value [org.apache.myfaces.config.runtimecon...@33d063fd]) but failed to remove it when the web application was stopped. This is very likely to create a memory leak. I don't know if the RuntimeConfig could be the one responsible of the leak in Jboss? That's exactly the kind of leak that Mojarra had. The other leak I've been seeing in code lately is where you use a WeakHashMap and the value contains the key. Your key/value will never be removed in that case. See the WeakHashMap javadoc if you aren't familiar with that leak. Bruno On 15 October 2010 13:12, ssilv...@redhat.com wrote: Thanks Werner. Hope someone can take a look before 2.0.3. Stan Quoting Werner Punz werner.p...@gmail.com: Am 15.10.10 14:04, schrieb ssilv...@redhat.com: I'm pretty sure 2.0.1 has a memory leak on undeploy. Mojarra had an undeploy leak and it took a long time to track it down. The same test I was using on Mojarra also failed on MyFaces but I haven't had time to track down the leak in MyFaces. Maybe this is fixed in 2.0.2? If not maybe someone can go ahead and take a look? The mem leak keeps MyFaces from passing TCK on JBoss AS. To test, all you need to do is create a small exploaded JSF app. Then have a script that touches web.xml every 10 seconds. That will cause the app to redeploy. You will get a PermGen error in about an hour. Hi Stan I opened a ticket under https://issues.apache.org/jira/browse/MYFACES-2942 Just to make sure the info is not lost. I hope you dont mind that I just copy pasted the info you gave here. Werner -- Matthias Wessendorf blog: http://matthiaswessendorf.wordpress.com/ sessions: http://www.slideshare.net/mwessendorf twitter: http://twitter.com/mwessendorf
Memory Leaks ... (was: Re: JBoss and MyFaces ....)
Oh, the tomcat folks have a good write on this topic: http://wiki.apache.org/tomcat/MemoryLeakProtection On Thu, Oct 28, 2010 at 10:33 AM, Matthias Wessendorf mat...@apache.org wrote: In Tomcat I also see this, using 2.0.2: points to StartupFacesContextImpl and to RuntimeConfig as well .10.2010 15:37:54 org.apache.catalina.loader.WebappClassLoader clearThreadLocalMap SCHWERWIEGEND: The web application [/webprofile] created a ThreadLocal with key of type [java.lang.ThreadLocal] (value [java.lang.threadlo...@203822fc]) and a value of type [org.apache.myfaces.context.servlet.StartupFacesContextImpl] (value [org.apache.myfaces.context.servlet.startupfacescontexti...@4580deea]) but failed to remove it when the web application was stopped. This is very likely to create a memory leak. 27.10.2010 15:37:54 org.apache.catalina.loader.WebappClassLoader clearThreadLocalMap SCHWERWIEGEND: The web application [/webprofile] created a ThreadLocal with key of type [java.lang.ThreadLocal] (value [java.lang.threadlo...@faaf84c]) and a value of type [org.apache.myfaces.context.servlet.StartupFacesContextImpl] (value [org.apache.myfaces.context.servlet.startupfacescontexti...@21934d9d]) but failed to remove it when the web application was stopped. This is very likely to create a memory leak. 27.10.2010 15:37:54 org.apache.catalina.loader.WebappClassLoader clearThreadLocalMap SCHWERWIEGEND: The web application [/webprofile] created a ThreadLocal with key of type [java.lang.ThreadLocal] (value [java.lang.threadlo...@4dcc8fa3]) and a value of type [org.apache.myfaces.config.RuntimeConfig] (value [org.apache.myfaces.config.runtimecon...@30ea3e3c]) but failed to remove it when the web application was stopped. This is very likely to create a memory leak. .Matthias On Fri, Oct 15, 2010 at 2:36 PM, ssilv...@redhat.com wrote: Quoting Bruno Aranda brunoara...@gmail.com: Using tomcat 7 I get this warning... SEVERE: The web application [/editor-2.0-SNAPSHOT] created a ThreadLocal with key of type [java.lang.ThreadLocal] (value [java.lang.threadlo...@41649a55]) and a value of type [org.apache.myfaces.config.RuntimeConfig] (value [org.apache.myfaces.config.runtimecon...@33d063fd]) but failed to remove it when the web application was stopped. This is very likely to create a memory leak. I don't know if the RuntimeConfig could be the one responsible of the leak in Jboss? That's exactly the kind of leak that Mojarra had. The other leak I've been seeing in code lately is where you use a WeakHashMap and the value contains the key. Your key/value will never be removed in that case. See the WeakHashMap javadoc if you aren't familiar with that leak. Bruno On 15 October 2010 13:12, ssilv...@redhat.com wrote: Thanks Werner. Hope someone can take a look before 2.0.3. Stan Quoting Werner Punz werner.p...@gmail.com: Am 15.10.10 14:04, schrieb ssilv...@redhat.com: I'm pretty sure 2.0.1 has a memory leak on undeploy. Mojarra had an undeploy leak and it took a long time to track it down. The same test I was using on Mojarra also failed on MyFaces but I haven't had time to track down the leak in MyFaces. Maybe this is fixed in 2.0.2? If not maybe someone can go ahead and take a look? The mem leak keeps MyFaces from passing TCK on JBoss AS. To test, all you need to do is create a small exploaded JSF app. Then have a script that touches web.xml every 10 seconds. That will cause the app to redeploy. You will get a PermGen error in about an hour. Hi Stan I opened a ticket under https://issues.apache.org/jira/browse/MYFACES-2942 Just to make sure the info is not lost. I hope you dont mind that I just copy pasted the info you gave here. Werner -- Matthias Wessendorf blog: http://matthiaswessendorf.wordpress.com/ sessions: http://www.slideshare.net/mwessendorf twitter: http://twitter.com/mwessendorf -- Matthias Wessendorf blog: http://matthiaswessendorf.wordpress.com/ sessions: http://www.slideshare.net/mwessendorf twitter: http://twitter.com/mwessendorf
Re: JBoss and MyFaces ....
Should be fixed in current snapshot ;) Regards, Jakob 2010/10/28 Matthias Wessendorf mat...@apache.org: In Tomcat I also see this, using 2.0.2: points to StartupFacesContextImpl and to RuntimeConfig as well .10.2010 15:37:54 org.apache.catalina.loader.WebappClassLoader clearThreadLocalMap SCHWERWIEGEND: The web application [/webprofile] created a ThreadLocal with key of type [java.lang.ThreadLocal] (value [java.lang.threadlo...@203822fc]) and a value of type [org.apache.myfaces.context.servlet.StartupFacesContextImpl] (value [org.apache.myfaces.context.servlet.startupfacescontexti...@4580deea]) but failed to remove it when the web application was stopped. This is very likely to create a memory leak. 27.10.2010 15:37:54 org.apache.catalina.loader.WebappClassLoader clearThreadLocalMap SCHWERWIEGEND: The web application [/webprofile] created a ThreadLocal with key of type [java.lang.ThreadLocal] (value [java.lang.threadlo...@faaf84c]) and a value of type [org.apache.myfaces.context.servlet.StartupFacesContextImpl] (value [org.apache.myfaces.context.servlet.startupfacescontexti...@21934d9d]) but failed to remove it when the web application was stopped. This is very likely to create a memory leak. 27.10.2010 15:37:54 org.apache.catalina.loader.WebappClassLoader clearThreadLocalMap SCHWERWIEGEND: The web application [/webprofile] created a ThreadLocal with key of type [java.lang.ThreadLocal] (value [java.lang.threadlo...@4dcc8fa3]) and a value of type [org.apache.myfaces.config.RuntimeConfig] (value [org.apache.myfaces.config.runtimecon...@30ea3e3c]) but failed to remove it when the web application was stopped. This is very likely to create a memory leak. .Matthias On Fri, Oct 15, 2010 at 2:36 PM, ssilv...@redhat.com wrote: Quoting Bruno Aranda brunoara...@gmail.com: Using tomcat 7 I get this warning... SEVERE: The web application [/editor-2.0-SNAPSHOT] created a ThreadLocal with key of type [java.lang.ThreadLocal] (value [java.lang.threadlo...@41649a55]) and a value of type [org.apache.myfaces.config.RuntimeConfig] (value [org.apache.myfaces.config.runtimecon...@33d063fd]) but failed to remove it when the web application was stopped. This is very likely to create a memory leak. I don't know if the RuntimeConfig could be the one responsible of the leak in Jboss? That's exactly the kind of leak that Mojarra had. The other leak I've been seeing in code lately is where you use a WeakHashMap and the value contains the key. Your key/value will never be removed in that case. See the WeakHashMap javadoc if you aren't familiar with that leak. Bruno On 15 October 2010 13:12, ssilv...@redhat.com wrote: Thanks Werner. Hope someone can take a look before 2.0.3. Stan Quoting Werner Punz werner.p...@gmail.com: Am 15.10.10 14:04, schrieb ssilv...@redhat.com: I'm pretty sure 2.0.1 has a memory leak on undeploy. Mojarra had an undeploy leak and it took a long time to track it down. The same test I was using on Mojarra also failed on MyFaces but I haven't had time to track down the leak in MyFaces. Maybe this is fixed in 2.0.2? If not maybe someone can go ahead and take a look? The mem leak keeps MyFaces from passing TCK on JBoss AS. To test, all you need to do is create a small exploaded JSF app. Then have a script that touches web.xml every 10 seconds. That will cause the app to redeploy. You will get a PermGen error in about an hour. Hi Stan I opened a ticket under https://issues.apache.org/jira/browse/MYFACES-2942 Just to make sure the info is not lost. I hope you dont mind that I just copy pasted the info you gave here. Werner -- Matthias Wessendorf blog: http://matthiaswessendorf.wordpress.com/ sessions: http://www.slideshare.net/mwessendorf twitter: http://twitter.com/mwessendorf -- Jakob Korherr blog: http://www.jakobk.com twitter: http://twitter.com/jakobkorherr work: http://www.irian.at
[jira] Commented: (MYFACES-2944) Make those add*** methods public in WebXml
[
https://issues.apache.org/jira/browse/MYFACES-2944?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=12925758#action_12925758
]
Jakob Korherr commented on MYFACES-2944:
Please also add this method to WebConfig:
protected boolean isFacesServlet(Class? servletClass) {
return FacesServlet.class.isAssignableFrom(servletClass) ||
DelegatedFacesServlet.class.isAssignableFrom(servletClass) ||
servletClass.getName().equals(getDelegateFacesServlet());
}
It will make the life of SPI providers easier!
Also: how are you planning to include the isOld() or the update() methods?
Make those add*** methods public in WebXml
--
Key: MYFACES-2944
URL: https://issues.apache.org/jira/browse/MYFACES-2944
Project: MyFaces Core
Issue Type: Improvement
Components: General
Affects Versions: 2.0.2
Reporter: Ivan
Assignee: Jakob Korherr
Fix For: 2.0.3-SNAPSHOT
Attachments: MYFACES-2944-core.patch, MYFACES-2944-shared.patch,
MYFACES-2944.patch
In the Geronimo integration work, we have an internal structure for the
parsed web.xml file, and we hope to use that instance to fill in the
org.apache.myfaces.shared.webapp.webxml.WebXml, so that myfaces does not need
to parse the web.xml file again, But those add*** method are package scope.
Is it possible to make those methods public, I did not see it will break
anyting.
Thanks
--
This message is automatically generated by JIRA.
-
You can reply to this email to add a comment to the issue online.
[jira] Commented: (MYFACES-2942) Memory Leak in MyFaces 2.0.1 probably as well in 2.0.2
[ https://issues.apache.org/jira/browse/MYFACES-2942?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=12925772#action_12925772 ] Jakob Korherr commented on MYFACES-2942: I just committed the last discussed point for this issue. Does anyone still see memory leaks or problems with ThreadLocals or something similar? If not, I will resolve this one. Memory Leak in MyFaces 2.0.1 probably as well in 2.0.2 -- Key: MYFACES-2942 URL: https://issues.apache.org/jira/browse/MYFACES-2942 Project: MyFaces Core Issue Type: Bug Affects Versions: 2.0.1, 2.0.2 Environment: JBOSS AS Reporter: Werner Punz Assignee: Jakob Korherr Priority: Critical Attachments: MYFACES-2942-RuntimeConfig.patch Stan Silvert from JBoss reports: I'm pretty sure 2.0.1 has a memory leak on undeploy. Mojarra had an undeploy leak and it took a long time to track it down. The same test I was using on Mojarra also failed on MyFaces but I haven't had time to track down the leak in MyFaces. Maybe this is fixed in 2.0.2? If not maybe someone can go ahead and take a look? The mem leak keeps MyFaces from passing TCK on JBoss AS. To test, all you need to do is create a small exploaded JSF app. Then have a script that touches web.xml every 10 seconds. That will cause the app to redeploy. You will get a PermGen error in about an hour. -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online.
[jira] Created: (TOBAGO-932) Text of labels is too much shifted to the top
Text of labels is too much shifted to the top - Key: TOBAGO-932 URL: https://issues.apache.org/jira/browse/TOBAGO-932 Project: MyFaces Tobago Issue Type: Improvement Affects Versions: 1.0.30 Environment: Firefox 3.6.11; (additional affected version: Tobago version currently used in the official demo, see below). Reporter: D. W. Priority: Trivial Dear all, The text of all labels is too much shifted to the top. Examples can be seen in the Tobago Demo for any of those themes: Richmond, Speyside, Charlotteville (http://www.irian.biz/tobago-example-demo). I think the label text should rather be vertically centered. Many greetings, dom -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online.
Re: [Trinidad] I updated the Trinidad site (browsers.xml), any one know how to get it updated on the web?
The continuum (that publishes the site) is down. You could manually replace the file on the server, in the meantime -Matthias On Wed, Oct 27, 2010 at 10:57 PM, Andrew Robinson arobinso...@apache.org wrote: Looks like the trinidad pom file is wrong and still lists continuum as the continuous integration piece in the pom.xml. I do not see where on hudson that the Trinidad site is listed as a project. Anyone know how to get the site re-deployed? Also anyone know the correct URL for hudson in the pom.xml? It is currently: ciManagement systemcontinuum/system urlhttp://myfaces.zones.apache.org:8080/continuum/url notifiers notifier typemail/type sendOnSuccesstrue/sendOnSuccess configuration addresscomm...@myfaces.apache.org/address /configuration /notifier /notifiers /ciManagement Thanks, Andrew -- Matthias Wessendorf blog: http://matthiaswessendorf.wordpress.com/ sessions: http://www.slideshare.net/mwessendorf twitter: http://twitter.com/mwessendorf
RE: NPE in Required Initialization for labels addon (property version)
Great, I see the change in the bean-validation version.
Don't forget the property version ;)
# This patch file was generated by NetBeans IDE
# It uses platform neutral UTF-8 encoding and \n newlines.
--- Base (BASE)
+++ Locally Modified (Based On LOCAL)
@@ -117,8 +117,11 @@
}
else
{
+String value = (String) uiOutput.getValue();
+if (value != null) {
applyRequiredMarkerUsingValue(facesContext, uiOutput, (String)
uiOutput.getValue());
}
+}
if (setEscapeToFalse)
{
doSetEscapeToFalse(uiOutput);
--Ben
-Original Message-
From: Gerhard [mailto:gerhard.petra...@gmail.com]
Sent: Wednesday, October 27, 2010 6:32 PM
To: MyFaces Development
Subject: Re: NPE in Required Initialization for labels addon (property version)
thx ben - i've committed it.
regards,
gerhard
http://www.irian.at
Your JSF powerhouse -
JSF Consulting, Development and
Courses in English and German
Professional Support for Apache MyFaces
2010/10/27 neum...@ijet.com
This null-check was also needed in the Bean Validation version.
Thanks!
Ben
-Original Message-
From: Ben Neuman
Sent: Wednesday, October 27, 2010 11:31 AM
To: 'MyFaces Development'
Subject: NPE in Required Initialization for labels addon (property version)
I had to make a small change in the Required Initialization for labels
(property version) to resolve a NullPointerException.
In DefaultRequiredLabelInitializer I added a null value check. Without, I was
getting NullPointerExceptions.
protected void applyRequiredMarker(FacesContext facesContext, UIOutput
uiOutput)
{
ValueExpression expression = uiOutput.getValueExpression(value);
if (expression != null)
{
applyRequiredMarkerUsingExpression(facesContext, uiOutput,
expression.getExpressionString());
}
else
{
String value = (String) uiOutput.getValue();
if (value != null) {
applyRequiredMarkerUsingValue(facesContext, uiOutput, value);
}
}
...
}
Thanks!
Ben
Re: [Trinidad] I updated the Trinidad site (browsers.xml), any one know how to get it updated on the web?
I thought that continuum was discontinued and we are supposed to be using hudson now. Is this not true? On Thu, Oct 28, 2010 at 6:00 AM, Matthias Wessendorf mat...@apache.org wrote: The continuum (that publishes the site) is down. You could manually replace the file on the server, in the meantime -Matthias On Wed, Oct 27, 2010 at 10:57 PM, Andrew Robinson arobinso...@apache.org wrote: Looks like the trinidad pom file is wrong and still lists continuum as the continuous integration piece in the pom.xml. I do not see where on hudson that the Trinidad site is listed as a project. Anyone know how to get the site re-deployed? Also anyone know the correct URL for hudson in the pom.xml? It is currently: ciManagement systemcontinuum/system urlhttp://myfaces.zones.apache.org:8080/continuum/url notifiers notifier typemail/type sendOnSuccesstrue/sendOnSuccess configuration addresscomm...@myfaces.apache.org/address /configuration /notifier /notifiers /ciManagement Thanks, Andrew -- Matthias Wessendorf blog: http://matthiaswessendorf.wordpress.com/ sessions: http://www.slideshare.net/mwessendorf twitter: http://twitter.com/mwessendorf
Required Label Marker Placement
Hi all. I've been playing with the required label addon and have found that a modification in marker rendering has improved the appearance of my app. I just want to get feedback from the rest as to whether this might be a change worth integrating into your module. Essentially, the current implementation simply prepends the marker to the label (when applying marker before value). Visually, I do not like my required marker displacing the label. I would prefer that all labels, required and otherwise, align vertically based on the label text, and that the required markers appear left of this vertical alignment. As so: *First Name: *Last Name: Middle Name: In order to do this, I've prepended the required marker where necessary and a space where not necessary. I have also set the font of the 'marker' to monospace. Would this be a worthy addition to the addon? We could of course allow the developer to turn this off through some configuration param. Thanks! Ben Neuman
Re: NPE in Required Initialization for labels addon (property version)
hi ben,
i've committed both - see [1]
regards,
gerhard
[1] http://code.google.com/p/os890/source/detail?r=378
http://www.irian.at
Your JSF powerhouse -
JSF Consulting, Development and
Courses in English and German
Professional Support for Apache MyFaces
2010/10/28 neum...@ijet.com
Great, I see the change in the bean-validation version.
Don't forget the property version ;)
# This patch file was generated by NetBeans IDE
# It uses platform neutral UTF-8 encoding and \n newlines.
--- Base (BASE)
+++ Locally Modified (Based On LOCAL)
@@ -117,8 +117,11 @@
}
else
{
+String value = (String) uiOutput.getValue();
+if (value != null) {
applyRequiredMarkerUsingValue(facesContext, uiOutput, (String)
uiOutput.getValue());
}
+}
if (setEscapeToFalse)
{
doSetEscapeToFalse(uiOutput);
--Ben
-Original Message-
*From:* Gerhard [mailto:gerhard.petra...@gmail.com]
*Sent:* Wednesday, October 27, 2010 6:32 PM
*To:* MyFaces Development
*Subject:* Re: NPE in Required Initialization for labels addon (property
version)
thx ben - i've committed it.
regards,
gerhard
http://www.irian.at
Your JSF powerhouse -
JSF Consulting, Development and
Courses in English and German
Professional Support for Apache MyFaces
2010/10/27 neum...@ijet.com
This null-check was also needed in the Bean Validation version.
Thanks!
Ben
-Original Message-
*From:* Ben Neuman
*Sent:* Wednesday, October 27, 2010 11:31 AM
*To:* 'MyFaces Development'
*Subject:* NPE in Required Initialization for labels addon (property
version)
I had to make a small change in the Required Initialization for labels
(property version) to resolve a NullPointerException.
In DefaultRequiredLabelInitializer I added a null value check. Without, I
was getting NullPointerExceptions.
protected void applyRequiredMarker(FacesContext facesContext, UIOutput
uiOutput)
{
ValueExpression expression = uiOutput.getValueExpression(value);
if (expression != null)
{
applyRequiredMarkerUsingExpression(facesContext, uiOutput,
expression.getExpressionString());
}
else
{
String value = (String) uiOutput.getValue();
if (value != null) {
applyRequiredMarkerUsingValue(facesContext, uiOutput,
value);
}
}
...
}
Thanks!
Ben
Re: Required Label Marker Placement
+1 i'll review and apply the patch as soon as you have finished the mentioned features. regards, gerhard http://www.irian.at Your JSF powerhouse - JSF Consulting, Development and Courses in English and German Professional Support for Apache MyFaces 2010/10/28 neum...@ijet.com Hi all. I've been playing with the required label addon and have found that a modification in marker rendering has improved the appearance of my app. I just want to get feedback from the rest as to whether this might be a change worth integrating into your module. Essentially, the current implementation simply prepends the marker to the label (when applying marker before value). Visually, I do not like my required marker displacing the label. I would prefer that all labels, required and otherwise, align vertically based on the label text, and that the required markers appear left of this vertical alignment. As so: *First Name: *Last Name: Middle Name: In order to do this, I've prepended the required marker where necessary and a space where not necessary. I have also set the font of the 'marker' to monospace. Would this be a worthy addition to the addon? We could of course allow the developer to turn this off through some configuration param. Thanks! Ben Neuman
Re: EL method invocation performance
Hi,
hi martin,
it would be nice to get more details about the juel issues.
Christian fixed them promptly in JUEL's svn:
http://sourceforge.net/tracker/?func=detailaid=3095122group_id=165179atid=834616
http://sourceforge.net/tracker/?func=detailaid=3031783group_id=165179atid=834616
Back to original topic: JUEL caches the ExpressionFactory instance and
thus does not have discussed performance problem.
regards,
gerhard
http://www.irian.at
Your JSF powerhouse -
JSF Consulting, Development and
Courses in English and German
Professional Support for Apache MyFaces
2010/10/19 Martin Koci martin.kocicak.k...@gmail.com
Hi,
some news about EL method invocations:
1) Geronimo EL API implementation has this problem too:
https://issues.apache.org/jira/browse/GERONIMO-5657
2) UEL bug is still open:
https://uel.dev.java.net/issues/show_bug.cgi?id=19
3) JUEL doesn't not work for my test cases, for example it
doesn't find
some public methods so I cannot say if JUEL has this problem
now.
My today's recommedation (which can change tommorow) is: if
you want EL
method invocations without file asscess within
(without /META-INF/services reading):
A) apply GERONIMO-5657 patch to
http://svn.apache.org/repos/asf/geronimo/specs/trunk/geronimo-el_2.2_spec/
and build this EL-API
B) use impl part from uel.dev.java.net as EL-impl or tomcat's
EL impl
Please note that uel.dev.java.net API suffers from classic
leaking
classloader problem too - it uses Class instance as key in
static Map :
see MYFACES-2942 for details. Maybe we should put a warning
about these
two issues at http://wiki.apache.org/myfaces/HowToEnableEl22 ?
Regards,
Kocicak
Martin Koci píše v St 25. 08. 2010 v 20:52 +0200:
Hi,
I'll try it but not today :) Optimization is my priority
task for next
few months and certainly I'll compare all four (or more?) EL
implementations.
Mark Struberg píše v St 25. 08. 2010 v 17:52 +:
Martin, could you please give juel a quick try? Would be
interested if if also
suffers from this problem.
You can find a slightly tweaked (bugfixed) version of it
on my github page
http://github.com/struberg/juel
The original is on juel.sourceforge.net
LieGrue,
strub
From: Jakob Korherr jakob.korh...@gmail.com
To: MyFaces Development dev@myfaces.apache.org
Sent: Wed, August 25, 2010 5:10:09 PM
Subject: Re: EL method invocation performance
Hi,
Does this really have to happen at every method
invocation or is this an
implementation problem?
If it is an implementation problem and can be circumvent
in any way, I would
contact the Glassfish and Tomcat developers about this ;)
Regards,
Jakob
2010/8/25 Ivan xhh...@gmail.com
How about trying the el api published by Geronimo ? it
caches the
ExpressionFactory to avoid the search action by default.
2010/8/25 Martin Koci martin.k...@aura.cz
Hi,
this problem is not in myfaces but affects performance
especially in
render response phase:
EL 2.2 introduces method invocation but if you try use
it like
rendered=#{bean.getRendered(param)} there is an
unpleasant surprise:
both implementations of BeanELResolver (Glassfish,
Tomcat) use this
construction during method invocation:
ExpressionFactory exprFactory =
ExpressionFactory.newInstance();
That newInstance() always involves FactoryFinder
mechanism, callstack
then looks like :
org.apache.catalina.loader.WebappClassLoader.findResourceInternal
org.apache.catalina.loader.WebappClassLoader.findResource
org.apache.catalina.loader.WebappClassLoader.getResourceAsStream
javax.el.FactoryFinder.find(String, String,
Properties)
javax.el.ExpressionFactory.newInstance(Properties)
javax.el.ExpressionFactory.newInstance()
Re: EL method invocation performance
@fixed juel: great!
regards,
gerhard
http://www.irian.at
Your JSF powerhouse -
JSF Consulting, Development and
Courses in English and German
Professional Support for Apache MyFaces
2010/10/28 Martin Koci martin.kocicak.k...@gmail.com
Hi,
hi martin,
it would be nice to get more details about the juel issues.
Christian fixed them promptly in JUEL's svn:
http://sourceforge.net/tracker/?func=detailaid=3095122group_id=165179atid=834616
http://sourceforge.net/tracker/?func=detailaid=3031783group_id=165179atid=834616
Back to original topic: JUEL caches the ExpressionFactory instance and
thus does not have discussed performance problem.
regards,
gerhard
http://www.irian.at
Your JSF powerhouse -
JSF Consulting, Development and
Courses in English and German
Professional Support for Apache MyFaces
2010/10/19 Martin Koci martin.kocicak.k...@gmail.com
Hi,
some news about EL method invocations:
1) Geronimo EL API implementation has this problem too:
https://issues.apache.org/jira/browse/GERONIMO-5657
2) UEL bug is still open:
https://uel.dev.java.net/issues/show_bug.cgi?id=19
3) JUEL doesn't not work for my test cases, for example it
doesn't find
some public methods so I cannot say if JUEL has this problem
now.
My today's recommedation (which can change tommorow) is: if
you want EL
method invocations without file asscess within
(without /META-INF/services reading):
A) apply GERONIMO-5657 patch to
http://svn.apache.org/repos/asf/geronimo/specs/trunk/geronimo-el_2.2_spec/and
build this EL-API
B) use impl part from uel.dev.java.net as EL-impl or tomcat's
EL impl
Please note that uel.dev.java.net API suffers from classic
leaking
classloader problem too - it uses Class instance as key in
static Map :
see MYFACES-2942 for details. Maybe we should put a warning
about these
two issues at http://wiki.apache.org/myfaces/HowToEnableEl22 ?
Regards,
Kocicak
Martin Koci píše v St 25. 08. 2010 v 20:52 +0200:
Hi,
I'll try it but not today :) Optimization is my priority
task for next
few months and certainly I'll compare all four (or more?) EL
implementations.
Mark Struberg píše v St 25. 08. 2010 v 17:52 +:
Martin, could you please give juel a quick try? Would be
interested if if also
suffers from this problem.
You can find a slightly tweaked (bugfixed) version of it
on my github page
http://github.com/struberg/juel
The original is on juel.sourceforge.net
LieGrue,
strub
From: Jakob Korherr jakob.korh...@gmail.com
To: MyFaces Development dev@myfaces.apache.org
Sent: Wed, August 25, 2010 5:10:09 PM
Subject: Re: EL method invocation performance
Hi,
Does this really have to happen at every method
invocation or is this an
implementation problem?
If it is an implementation problem and can be circumvent
in any way, I would
contact the Glassfish and Tomcat developers about this ;)
Regards,
Jakob
2010/8/25 Ivan xhh...@gmail.com
How about trying the el api published by Geronimo ? it
caches the
ExpressionFactory to avoid the search action by default.
2010/8/25 Martin Koci martin.k...@aura.cz
Hi,
this problem is not in myfaces but affects performance
especially in
render response phase:
EL 2.2 introduces method invocation but if you try use
it like
rendered=#{bean.getRendered(param)} there is an
unpleasant surprise:
both implementations of BeanELResolver (Glassfish,
Tomcat) use this
construction during method invocation:
ExpressionFactory exprFactory =
ExpressionFactory.newInstance();
That newInstance() always involves FactoryFinder
mechanism, callstack
then looks like :
org.apache.catalina.loader.WebappClassLoader.findResourceInternal
org.apache.catalina.loader.WebappClassLoader.findResource
org.apache.catalina.loader.WebappClassLoader.getResourceAsStream
Re: Memory Leaks ... (was: Re: JBoss and MyFaces ....)
I started reading the link you posted and ended up here: This also talks about classloader memory leaks in general, how to identify them using the Eclipse Memory Analyzer (can also be run as a standalone app), and how to determine what needs to be done to fix them. http://dev.eclipse.org/blogs/memoryanalyzer/2008/05/17/the-unknown-generation-perm/ On Thu, Oct 28, 2010 at 4:35 AM, Matthias Wessendorf mat...@apache.org wrote: Oh, the tomcat folks have a good write on this topic: http://wiki.apache.org/tomcat/MemoryLeakProtection On Thu, Oct 28, 2010 at 10:33 AM, Matthias Wessendorf mat...@apache.org wrote: In Tomcat I also see this, using 2.0.2: points to StartupFacesContextImpl and to RuntimeConfig as well .10.2010 15:37:54 org.apache.catalina.loader.WebappClassLoader clearThreadLocalMap SCHWERWIEGEND: The web application [/webprofile] created a ThreadLocal with key of type [java.lang.ThreadLocal] (value [java.lang.threadlo...@203822fc]) and a value of type [org.apache.myfaces.context.servlet.StartupFacesContextImpl] (value [org.apache.myfaces.context.servlet.startupfacescontexti...@4580deea]) but failed to remove it when the web application was stopped. This is very likely to create a memory leak. 27.10.2010 15:37:54 org.apache.catalina.loader.WebappClassLoader clearThreadLocalMap SCHWERWIEGEND: The web application [/webprofile] created a ThreadLocal with key of type [java.lang.ThreadLocal] (value [java.lang.threadlo...@faaf84c]) and a value of type [org.apache.myfaces.context.servlet.StartupFacesContextImpl] (value [org.apache.myfaces.context.servlet.startupfacescontexti...@21934d9d]) but failed to remove it when the web application was stopped. This is very likely to create a memory leak. 27.10.2010 15:37:54 org.apache.catalina.loader.WebappClassLoader clearThreadLocalMap SCHWERWIEGEND: The web application [/webprofile] created a ThreadLocal with key of type [java.lang.ThreadLocal] (value [java.lang.threadlo...@4dcc8fa3]) and a value of type [org.apache.myfaces.config.RuntimeConfig] (value [org.apache.myfaces.config.runtimecon...@30ea3e3c]) but failed to remove it when the web application was stopped. This is very likely to create a memory leak. .Matthias On Fri, Oct 15, 2010 at 2:36 PM, ssilv...@redhat.com wrote: Quoting Bruno Aranda brunoara...@gmail.com: Using tomcat 7 I get this warning... SEVERE: The web application [/editor-2.0-SNAPSHOT] created a ThreadLocal with key of type [java.lang.ThreadLocal] (value [java.lang.threadlo...@41649a55]) and a value of type [org.apache.myfaces.config.RuntimeConfig] (value [org.apache.myfaces.config.runtimecon...@33d063fd]) but failed to remove it when the web application was stopped. This is very likely to create a memory leak. I don't know if the RuntimeConfig could be the one responsible of the leak in Jboss? That's exactly the kind of leak that Mojarra had. The other leak I've been seeing in code lately is where you use a WeakHashMap and the value contains the key. Your key/value will never be removed in that case. See the WeakHashMap javadoc if you aren't familiar with that leak. Bruno On 15 October 2010 13:12, ssilv...@redhat.com wrote: Thanks Werner. Hope someone can take a look before 2.0.3. Stan Quoting Werner Punz werner.p...@gmail.com: Am 15.10.10 14:04, schrieb ssilv...@redhat.com: I'm pretty sure 2.0.1 has a memory leak on undeploy. Mojarra had an undeploy leak and it took a long time to track it down. The same test I was using on Mojarra also failed on MyFaces but I haven't had time to track down the leak in MyFaces. Maybe this is fixed in 2.0.2? If not maybe someone can go ahead and take a look? The mem leak keeps MyFaces from passing TCK on JBoss AS. To test, all you need to do is create a small exploaded JSF app. Then have a script that touches web.xml every 10 seconds. That will cause the app to redeploy. You will get a PermGen error in about an hour. Hi Stan I opened a ticket under https://issues.apache.org/jira/browse/MYFACES-2942 Just to make sure the info is not lost. I hope you dont mind that I just copy pasted the info you gave here. Werner -- Matthias Wessendorf blog: http://matthiaswessendorf.wordpress.com/ sessions: http://www.slideshare.net/mwessendorf twitter: http://twitter.com/mwessendorf -- Matthias Wessendorf blog: http://matthiaswessendorf.wordpress.com/ sessions: http://www.slideshare.net/mwessendorf twitter: http://twitter.com/mwessendorf
[jira] Created: (TRINIDAD-1948) Trinidad's Agent API Should Support Detection of Web Crawlers
Trinidad's Agent API Should Support Detection of Web Crawlers - Key: TRINIDAD-1948 URL: https://issues.apache.org/jira/browse/TRINIDAD-1948 Project: MyFaces Trinidad Issue Type: New Feature Affects Versions: 2.0.0.3-core Reporter: Max Starets Assignee: Max Starets We should add support for detecting web crawlers at runtime. This would allow page authors to generate special content for the search engines, and would enable us in the future to implement a special rendering mode if we choose to do so. Proposal: - Add new TYPE_WEBCRAWLER Agent type - Add AGENT_GOOGLEBOT and AGENT_MSNBOT agents - Use the desktop rendering kit and the default output mode when generating content for web crawlers (for now). -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online.
[jira] Updated: (TRINIDAD-1948) Trinidad's Agent API Should Support Detection of Web Crawlers
[ https://issues.apache.org/jira/browse/TRINIDAD-1948?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Max Starets updated TRINIDAD-1948: -- Status: Patch Available (was: Open) Trinidad's Agent API Should Support Detection of Web Crawlers - Key: TRINIDAD-1948 URL: https://issues.apache.org/jira/browse/TRINIDAD-1948 Project: MyFaces Trinidad Issue Type: New Feature Affects Versions: 2.0.0.3-core Reporter: Max Starets Assignee: Max Starets We should add support for detecting web crawlers at runtime. This would allow page authors to generate special content for the search engines, and would enable us in the future to implement a special rendering mode if we choose to do so. Proposal: - Add new TYPE_WEBCRAWLER Agent type - Add AGENT_GOOGLEBOT and AGENT_MSNBOT agents - Use the desktop rendering kit and the default output mode when generating content for web crawlers (for now). -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online.
[jira] Reopened: (MYFACES-2946) composite:attribute targets property does not match with ViewDeclarationLanguage.retargetMethodExpressions
[ https://issues.apache.org/jira/browse/MYFACES-2946?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Leonardo Uribe reopened MYFACES-2946: - Checking how this algorithm works, I found a misunderstanding between two concepts: - It is necessary to save the object created for actionListener, validator and valueChangeListener, so we can revert them later when we resolve a nested retargetMethodExpressions. That should be saved for each target component. - It is necessary to mark the attribute on the composite component parent, to prevent apply twice the algorithm when a nested retargetMethodExpressions is called. For do both I tried to use just one map, but clearly the intention require use a different map for each one of them, so we need to refactor the algorithm properly. composite:attribute targets property does not match with ViewDeclarationLanguage.retargetMethodExpressions Key: MYFACES-2946 URL: https://issues.apache.org/jira/browse/MYFACES-2946 Project: MyFaces Core Issue Type: Bug Components: JSR-314 Affects Versions: 2.0.2 Reporter: Leonardo Uribe Assignee: Leonardo Uribe Fix For: 2.0.3-SNAPSHOT Attachments: MYFACES-2946-1.patch Some days ago, it was mentioned on myfaces dev list that targets attribute does not seem to work as expected. After review the available documentation and doing some test, my conclusion was the spec is good, but this part needs a little bit more documentation (and fix some bugs), because there are use cases that are causing problems to users. Some of these problems has been already mentioned (spec issue 755) but my intention here is do a full and detailed analysis. The property targets is used for these tags: composite:actionSource composite:editableValueHolder composite:valueHolder composite:clientBehavior composite:attribute For the first four cases, this property is used by : ViewDeclarationLanguage.retargetAttachedObjects(FacesContext context, UIComponent topLevelComponent, ListAttachedObjectHandler handlers) In JSF 2.0 rev A it was made explicit the need to handle nested composite component with this lines: ... The implementation must support retargeting attached objects from the top level compsite component to targets that are composite and non-composite components This is ok ;-). The problem is the description about how composite:attribute targets property works does not match with the algorithm for: ViewDeclarationLanguage.retargetMethodExpressions(FacesContext context, UIComponent topLevelComponent) Here is the documentation about composite:attribute targets: ... If this element has a method-signature attribute, the value of the targets attribute must be interpreted as a space (not tab) separated list of client ids (relative to the top level component) of components within the composite:implementation section. Space is used as the delimiter for compatibility with the IDREFS and NMTOKENS data types from the XML Schema. Each entry in the list must be interpreted as the id of an inner component to which the MethodExpression from the composite component tag in the using page must be applied. If this element has a method-signature attribute, but no targets attribute, the value of the name attribute is used as the single entry in the list. If the value of the name attribute is not one of the special values listed in the description of the name attribute, targets (or its derived value) need not correspond to the id of an inner component At this point everything seems to be ok. But look this documentation (I'll put the important points): . # Get the value of the targets attribute. If the value is a ValueExpression evaluate it. If there is no targets attribute, let the name of the metadata element be the evaluated value of the targets attribute. # Interpret targets as a space (not tab) separated list of ids. For each entry in the list: .. # If name is equal to the string action without the quotes, call ActionSource2.setActionExpression(javax.el.MethodExpression) on target, passing attributeMethodExpression. # If name is equal to the string actionListener without the quotes, call ActionSource.addActionListener(javax.faces.event.ActionListener) on target, passing attributeMethodExpression wrapped in a MethodExpressionActionListener. # If name is equal to the string validator without the quotes, call EditableValueHolder.addValidator(javax.faces.validator.Validator) on target, passing
[jira] Resolved: (MYFACES-2946) composite:attribute targets property does not match with ViewDeclarationLanguage.retargetMethodExpressions
[ https://issues.apache.org/jira/browse/MYFACES-2946?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Leonardo Uribe resolved MYFACES-2946. - Resolution: Fixed composite:attribute targets property does not match with ViewDeclarationLanguage.retargetMethodExpressions Key: MYFACES-2946 URL: https://issues.apache.org/jira/browse/MYFACES-2946 Project: MyFaces Core Issue Type: Bug Components: JSR-314 Affects Versions: 2.0.2 Reporter: Leonardo Uribe Assignee: Leonardo Uribe Fix For: 2.0.3-SNAPSHOT Attachments: MYFACES-2946-1.patch Some days ago, it was mentioned on myfaces dev list that targets attribute does not seem to work as expected. After review the available documentation and doing some test, my conclusion was the spec is good, but this part needs a little bit more documentation (and fix some bugs), because there are use cases that are causing problems to users. Some of these problems has been already mentioned (spec issue 755) but my intention here is do a full and detailed analysis. The property targets is used for these tags: composite:actionSource composite:editableValueHolder composite:valueHolder composite:clientBehavior composite:attribute For the first four cases, this property is used by : ViewDeclarationLanguage.retargetAttachedObjects(FacesContext context, UIComponent topLevelComponent, ListAttachedObjectHandler handlers) In JSF 2.0 rev A it was made explicit the need to handle nested composite component with this lines: ... The implementation must support retargeting attached objects from the top level compsite component to targets that are composite and non-composite components This is ok ;-). The problem is the description about how composite:attribute targets property works does not match with the algorithm for: ViewDeclarationLanguage.retargetMethodExpressions(FacesContext context, UIComponent topLevelComponent) Here is the documentation about composite:attribute targets: ... If this element has a method-signature attribute, the value of the targets attribute must be interpreted as a space (not tab) separated list of client ids (relative to the top level component) of components within the composite:implementation section. Space is used as the delimiter for compatibility with the IDREFS and NMTOKENS data types from the XML Schema. Each entry in the list must be interpreted as the id of an inner component to which the MethodExpression from the composite component tag in the using page must be applied. If this element has a method-signature attribute, but no targets attribute, the value of the name attribute is used as the single entry in the list. If the value of the name attribute is not one of the special values listed in the description of the name attribute, targets (or its derived value) need not correspond to the id of an inner component At this point everything seems to be ok. But look this documentation (I'll put the important points): . # Get the value of the targets attribute. If the value is a ValueExpression evaluate it. If there is no targets attribute, let the name of the metadata element be the evaluated value of the targets attribute. # Interpret targets as a space (not tab) separated list of ids. For each entry in the list: .. # If name is equal to the string action without the quotes, call ActionSource2.setActionExpression(javax.el.MethodExpression) on target, passing attributeMethodExpression. # If name is equal to the string actionListener without the quotes, call ActionSource.addActionListener(javax.faces.event.ActionListener) on target, passing attributeMethodExpression wrapped in a MethodExpressionActionListener. # If name is equal to the string validator without the quotes, call EditableValueHolder.addValidator(javax.faces.validator.Validator) on target, passing attributeMethodExpression wrapped in a MethodExpressionValidator. # If name is equal to the string valueChangeListener without the quotes, call EditableValueHolder.addValueChangeListener(javax.faces.event.ValueChangeListener) on target, passing attributeMethodExpression wrapped in a MethodExpressionValueChangeListener. # Otherwise, assume that the MethodExpression should be placed in the components attribute set. The runtme must create the MethodExpression instance based on the value of the method-signature attribute. . My first interpretation of this
