MyFaces Core
  1. MyFaces Core
  2. MYFACES-1741

JSR-252 Issue 21 - Provided an additional "binding" attribute for the core Converter, Listener and Validator tags has wrong behaviour

    Details

    • Type: Bug Bug
    • Status: Closed
    • Priority: Major Major
    • Resolution: Fixed
    • Affects Version/s: 1.2.0
    • Fix Version/s: 1.2.2
    • Component/s: JSR-252
    • Labels:
      None
    • Environment:
      Tomcat 6.0.14, Myfaces 1.2.1-SNAPSHOT (Oct 7 2007)

      Description

      There is a problem with the behaviour of binding attribute from actionListeners, validators and converters.

      I have this test. The objective is explore how binding attribute is doing things comparing jsf ri 1.2 and
      myfaces 1.2.1-SNAPSHOT, trying to detect bugs on myfaces

      bindingCLV.jsp

      <%@ page session="false" contentType="text/html;charset=utf-8"%>
      <%@ taglib uri="http://java.sun.com/jsf/html" prefix="h"%>
      <%@ taglib uri="http://java.sun.com/jsf/core" prefix="f"%>

      <html>
      <f:view beforePhase="#

      {bindingCLVBean.beforePhase}

      "
      afterPhase="#

      {bindingCLVBean.afterPhase}

      ">
      <%@include file="inc/head.inc"%>
      <body>
      <f:loadBundle
      basename="org.apache.myfaces.examples.resource.example_messages"
      var="example_messages" />
      <h1>Myfaces Examples JSF 1.2 Additions</h1>
      <h:messages></h:messages>
      <h:form id="form">
      <h:panelGrid id="grid" columns="3">
      <h:outputLabel value="BigInt" for="bigint"></h:outputLabel>
      <h:inputText id="bigint" binding="#

      {bindingCLVBean.input1}

      " value="#

      {bindingCLVBean.bigint}

      ">
      <f:converter converterId="javax.faces.BigInteger" binding="#

      {bindingCLVBean.converterBigint}

      "/>
      <f:validator validatorId="org.apache.myfaces.bindingCLV.DummyValidator"
      binding="#

      {bindingCLVBean.validatorBigint}

      "/>
      </h:inputText>
      <h:message for="bigint"></h:message>
      <h:outputLabel value="BigDecimal" for="bigdecimal"></h:outputLabel>
      <h:inputText id="bigdecimal" binding="#

      {bindingCLVBean.input2}

      " value="#

      {bindingCLVBean.bigdecimal}

      ">
      <f:converter converterId="javax.faces.BigDecimal" binding="#

      {bindingCLVBean.converterBigdecimal}

      "/>
      <f:validator validatorId="org.apache.myfaces.bindingCLV.DummyValidator"
      binding="#

      {bindingCLVBean.validatorBigdecimal}

      "/>
      </h:inputText>
      <h:message for="bigdecimal"></h:message>
      </h:panelGrid>
      <h:commandButton id="button1" value="press me" action="#

      {bindingCLVBean.update}

      " >
      <f:actionListener type="org.apache.myfaces.bindingCLV.DummyActionListener"
      binding="#

      {bindingCLVBean.listener}

      " />
      </h:commandButton>
      </h:form>
      </body>
      </f:view>
      </html>

      Bean:

      package org.apache.myfaces.bindingCLV;

      import java.math.BigDecimal;
      import java.math.BigInteger;

      import javax.faces.application.FacesMessage;
      import javax.faces.component.html.HtmlInputText;
      import javax.faces.context.FacesContext;
      import javax.faces.convert.Converter;
      import javax.faces.event.ActionListener;
      import javax.faces.event.PhaseEvent;
      import javax.faces.validator.Validator;

      import org.apache.commons.logging.Log;
      import org.apache.commons.logging.LogFactory;

      public class BindingCLVBean {

      private BigInteger bigint;

      private BigDecimal bigdecimal;

      private Converter converterBigint;

      private Converter converterBigdecimal;

      private Validator validatorBigint;

      private Validator validatorBigdecimal;

      private HtmlInputText input1;

      private HtmlInputText input2;

      private ActionListener listener;

      Log log = LogFactory.getLog(BindingCLVBean.class);

      public void beforePhase(PhaseEvent phaseEvent)

      { FacesContext facesContext = FacesContext.getCurrentInstance(); facesContext.addMessage(null, new FacesMessage("This is the message for phase before "+phaseEvent.getPhaseId().toString())); facesContext.addMessage(null, new FacesMessage("Component:"+this.getInput1())); facesContext.addMessage(null, new FacesMessage("Validator:"+this.getValidatorBigdecimal())); facesContext.addMessage(null, new FacesMessage("Converter:"+this.getConverterBigdecimal())); facesContext.addMessage(null, new FacesMessage("ActionListener:"+this.getListener())); log.info("This is the message for phase before "+phaseEvent.getPhaseId().toString()+" : "); }

      public void afterPhase(PhaseEvent phaseEvent)

      { FacesContext facesContext = FacesContext.getCurrentInstance(); facesContext.addMessage(null, new FacesMessage("This is the message for phase after "+phaseEvent.getPhaseId().toString())); facesContext.addMessage(null, new FacesMessage("Component:"+this.getInput1())); facesContext.addMessage(null, new FacesMessage("Validator:"+this.getValidatorBigdecimal())); facesContext.addMessage(null, new FacesMessage("Converter:"+this.getConverterBigdecimal())); facesContext.addMessage(null, new FacesMessage("ActionListener:"+this.getListener())); log.info("This is the message for phase after "+phaseEvent.getPhaseId().toString()+" : "); }

      public BigInteger getBigint()

      { return bigint; }

      public void setBigint(BigInteger bigint)

      { this.bigint = bigint; }

      public BigDecimal getBigdecimal()

      { return bigdecimal; }

      public void setBigdecimal(BigDecimal bigdecimal)

      { this.bigdecimal = bigdecimal; }

      public Converter getConverterBigint()

      { return converterBigint; }

      public void setConverterBigint(Converter converterBigint)

      { this.converterBigint = converterBigint; }

      public Converter getConverterBigdecimal()

      { return converterBigdecimal; }

      public void setConverterBigdecimal(Converter converterBigdecimal)

      { this.converterBigdecimal = converterBigdecimal; }

      public Validator getValidatorBigint()

      { return validatorBigint; }

      public void setValidatorBigint(Validator validatorBigint)

      { this.validatorBigint = validatorBigint; }

      public Validator getValidatorBigdecimal()

      { return validatorBigdecimal; }

      public void setValidatorBigdecimal(Validator validatorBigdecimal)

      { this.validatorBigdecimal = validatorBigdecimal; }

      public String update()

      { FacesContext context = FacesContext.getCurrentInstance(); return "update"; }

      public HtmlInputText getInput1()

      { return input1; }

      public void setInput1(HtmlInputText input1)

      { this.input1 = input1; }

      public HtmlInputText getInput2()

      { return input2; }

      public void setInput2(HtmlInputText input2)

      { this.input2 = input2; }

      public ActionListener getListener()

      { return listener; }

      public void setListener(ActionListener listener)

      { this.listener = listener; }

      }

      When you call the page the first time, this is the output for <h:messages> tag :

      JSF RI:

      • This is the message for phase before RENDER_RESPONSE 6
      • Component:javax.faces.component.html.HtmlInputText@164de59
      • Validator:null
      • Converter:null
      • ActionListener:null

      Myfaces:

      • This is the message for phase before RENDER_RESPONSE(6)
      • Component:javax.faces.component.html.HtmlInputText@18c5e67
      • Validator:org.apache.myfaces.bindingCLV.DummyValidator@89c116
      • Converter:javax.faces.convert.BigDecimalConverter@1e3bbd7
      • ActionListener:org.apache.myfaces.bindingCLV.DummyActionListener@4133b0

      QUESTION 1: Why do I create an object that I do not use?. Myfaces is wrong, and JSF RI has the correct behaviour.
      The first time that I load a page, it's unnecesary to create those objects.

      And when you press the button or submit the form:

      JSF RI:

      • This is the message for phase before APPLY_REQUEST_VALUES 2
      • Component:javax.faces.component.html.HtmlInputText@14aa2db
      • Validator:null
      • Converter:null
      • ActionListener:null
      • This is the message for phase after APPLY_REQUEST_VALUES 2
      • Component:javax.faces.component.html.HtmlInputText@14aa2db
      • Validator:null
      • Converter:null
      • ActionListener:null
      • This is the message for phase before PROCESS_VALIDATIONS 3
      • Component:javax.faces.component.html.HtmlInputText@14aa2db
      • Validator:null
      • Converter:null
      • ActionListener:null
      • This is the message for phase after PROCESS_VALIDATIONS 3
      • Component:javax.faces.component.html.HtmlInputText@14aa2db
      • Validator:org.apache.myfaces.bindingCLV.DummyValidator@10df4e2
      • Converter:javax.faces.convert.BigDecimalConverter@1485542
      • ActionListener:null
      • This is the message for phase before UPDATE_MODEL_VALUES 4
      • Component:javax.faces.component.html.HtmlInputText@14aa2db
      • Validator:org.apache.myfaces.bindingCLV.DummyValidator@10df4e2
      • Converter:javax.faces.convert.BigDecimalConverter@1485542
      • ActionListener:null
      • This is the message for phase after UPDATE_MODEL_VALUES 4
      • Component:javax.faces.component.html.HtmlInputText@14aa2db
      • Validator:org.apache.myfaces.bindingCLV.DummyValidator@10df4e2
      • Converter:javax.faces.convert.BigDecimalConverter@1485542
      • ActionListener:null
      • This is the message for phase before INVOKE_APPLICATION 5
      • Component:javax.faces.component.html.HtmlInputText@14aa2db
      • Validator:org.apache.myfaces.bindingCLV.DummyValidator@10df4e2
      • Converter:javax.faces.convert.BigDecimalConverter@1485542
      • ActionListener:null
      • This is the message for phase after INVOKE_APPLICATION 5
      • Component:javax.faces.component.html.HtmlInputText@14aa2db
      • Validator:org.apache.myfaces.bindingCLV.DummyValidator@10df4e2
      • Converter:javax.faces.convert.BigDecimalConverter@1485542
      • ActionListener:org.apache.myfaces.bindingCLV.DummyActionListener@391da0
      • This is the message for phase before RENDER_RESPONSE 6
      • Component:javax.faces.component.html.HtmlInputText@14aa2db
      • Validator:org.apache.myfaces.bindingCLV.DummyValidator@10df4e2
      • Converter:javax.faces.convert.BigDecimalConverter@1485542
      • ActionListener:org.apache.myfaces.bindingCLV.DummyActionListener@391da0

      Myfaces:

      • This is the message for phase before APPLY_REQUEST_VALUES(2)
      • Component:javax.faces.component.html.HtmlInputText@16752c9
      • Validator:null
      • Converter:null
      • ActionListener:null
      • This is the message for phase after APPLY_REQUEST_VALUES(2)
      • Component:javax.faces.component.html.HtmlInputText@16752c9
      • Validator:null
      • Converter:null
      • ActionListener:null
      • This is the message for phase before PROCESS_VALIDATIONS(3)
      • Component:javax.faces.component.html.HtmlInputText@16752c9
      • Validator:null
      • Converter:null
      • ActionListener:null
      • This is the message for phase after PROCESS_VALIDATIONS(3)
      • Component:javax.faces.component.html.HtmlInputText@16752c9
      • Validator:null
      • Converter:null
      • ActionListener:null
      • This is the message for phase before UPDATE_MODEL_VALUES(4)
      • Component:javax.faces.component.html.HtmlInputText@16752c9
      • Validator:null
      • Converter:null
      • ActionListener:null
      • This is the message for phase after UPDATE_MODEL_VALUES(4)
      • Component:javax.faces.component.html.HtmlInputText@16752c9
      • Validator:null
      • Converter:null
      • ActionListener:null
      • This is the message for phase before INVOKE_APPLICATION(5)
      • Component:javax.faces.component.html.HtmlInputText@16752c9
      • Validator:null
      • Converter:null
      • ActionListener:null
      • This is the message for phase after INVOKE_APPLICATION(5)
      • Component:javax.faces.component.html.HtmlInputText@16752c9
      • Validator:null
      • Converter:null
      • ActionListener:null
      • This is the message for phase before RENDER_RESPONSE(6)
      • Component:javax.faces.component.html.HtmlInputText@16752c9
      • Validator:org.apache.myfaces.bindingCLV.DummyValidator@1c958af
      • Converter:javax.faces.convert.BigDecimalConverter@1dd7736
      • ActionListener:org.apache.myfaces.bindingCLV.DummyActionListener@bd93cd

      QUESTION 2: Why I not have bindings assigned before INVOKE_APPLICATION ?(in this time is of value have a binding attribute) .
      Again JSF RI has the correct behaviour and Myfaces is wrong. Myfaces create the validators, converters and
      actionListeners on correct time, but not assign bindings when is supposed to do. If I assign a binding for
      converter, validator or actionListener, I should be assigned minimum before INVOKE_APPLICATION, or better,
      converters and validators on PROCESS_VALIDATIONS, and actionListeners in INVOKE_APPLICATION.

      Looks a little bit difficult but I will try to find a solution for this issue.

        Activity

        Hide
        Leonardo Uribe added a comment -

        The three binding properties from f:converter, f:validator and f:actionListener looks different,
        so i will concentrate first on a possible <f:converter> solution.

        Looking this issue in more deep, I have found some questions and answers:

        The spec doc says the following about <f:converter>:

        "..... The implementation class for this action must meet the following requirements:

        • Must extend javax.faces.webapp.ConverterJspTag.
        • The createConverter() method must:

        If binding is non-null, call binding.getValue() to obtain a reference to the
        Converter instance. If there is no exception thrown, and binding.getValue()
        returned a non-null object that implements javax.faces.convert.Converter,
        register it by calling setConverter(). If there was an exception thrown, rethrow
        the exception as a JspException.Use the converterId attribute if the converter
        instance could not be created from the binding attribute. If the converterId
        attribute is set, call the createConverter() method of the Application
        instance for this application, passing converter id specified by their converterId
        attribute. If the binding attribute was also set, store the converter instance by calling
        binding.setValue(). Register the converter instance by calling
        setConverter(). If there was an exception thrown, rethrow the exception as a
        JspException. "

        This is what myfaces do, implementing this behaviour on org.apache.myfaces.taglib.core.ConverterTag,
        and the actual behaviour of myfaces (it's doing what the spec says to do).

        CONCLUSION 1: Maybe this implementation detail refers to javax.faces.webapp.ConverterTag, which is
        now deprecated(but looking on jsf1.1 spec doc doesn't appear this paragraph). The actual behaviour
        of f:converter in JSF RI is different to the spec says(that is what the test says), maybe because
        the addition of binding attribute. Looking on core tld of JSF RI they use another class
        like myfaces, so I suppose that they are doing another thing there to do what actually does.

        So, if the previous conclusion is true, What should do a solution that works like JSF RI behaviour?
        (this behaviour is the spected behaviour for binding attribute):

        1. The state of the converter must be restored (binding and converterId) in order to be called later
        in PROCESS_VALIDATIONS phase .

        Now, the tree saves something like this:

        <html.HtmlInputText id="bigint" ... converter="javax.faces.convert.BigIntegerConverter@168e429" ....

        When the state is restored, this instace is called or recreated, so the binding is only assigned on ConverterTag.
        javax.faces.convert.BigIntegerConverter does not implement a StateHolder interface to save and
        restore the state, so I suppose that it is possible to create a class that implements Converter and StateHolder,
        and do something like a delegate pattern, to save converterId and binding values on the tree.

        2. Restore the binding when getConverter() is called or something like that.

        Show
        Leonardo Uribe added a comment - The three binding properties from f:converter, f:validator and f:actionListener looks different, so i will concentrate first on a possible <f:converter> solution. Looking this issue in more deep, I have found some questions and answers: The spec doc says the following about <f:converter>: "..... The implementation class for this action must meet the following requirements: Must extend javax.faces.webapp.ConverterJspTag. The createConverter() method must: If binding is non-null, call binding.getValue() to obtain a reference to the Converter instance. If there is no exception thrown, and binding.getValue() returned a non-null object that implements javax.faces.convert.Converter, register it by calling setConverter(). If there was an exception thrown, rethrow the exception as a JspException.Use the converterId attribute if the converter instance could not be created from the binding attribute. If the converterId attribute is set, call the createConverter() method of the Application instance for this application, passing converter id specified by their converterId attribute. If the binding attribute was also set, store the converter instance by calling binding.setValue(). Register the converter instance by calling setConverter(). If there was an exception thrown, rethrow the exception as a JspException. " This is what myfaces do, implementing this behaviour on org.apache.myfaces.taglib.core.ConverterTag, and the actual behaviour of myfaces (it's doing what the spec says to do). CONCLUSION 1: Maybe this implementation detail refers to javax.faces.webapp.ConverterTag, which is now deprecated(but looking on jsf1.1 spec doc doesn't appear this paragraph). The actual behaviour of f:converter in JSF RI is different to the spec says(that is what the test says), maybe because the addition of binding attribute. Looking on core tld of JSF RI they use another class like myfaces, so I suppose that they are doing another thing there to do what actually does. So, if the previous conclusion is true, What should do a solution that works like JSF RI behaviour? (this behaviour is the spected behaviour for binding attribute): 1. The state of the converter must be restored (binding and converterId) in order to be called later in PROCESS_VALIDATIONS phase . Now, the tree saves something like this: <html.HtmlInputText id="bigint" ... converter="javax.faces.convert.BigIntegerConverter@168e429" .... When the state is restored, this instace is called or recreated, so the binding is only assigned on ConverterTag. javax.faces.convert.BigIntegerConverter does not implement a StateHolder interface to save and restore the state, so I suppose that it is possible to create a class that implements Converter and StateHolder, and do something like a delegate pattern, to save converterId and binding values on the tree. 2. Restore the binding when getConverter() is called or something like that.
        Hide
        Leonardo Uribe added a comment -

        I have made a probe of my assumptions.

        If all previous discussion is true, what should return JSF RI UIOutput.getConverter() for any component that has a converter?

        If I use BigIntegerConverter, should return an object of the same type?

        I made a simple modification of the previous code. At each phase, print what is inside this property.

        As I hoped, it returns this

        1. This is the message for phase before APPLY_REQUEST_VALUES 2
        2. Component:javax.faces.component.html.HtmlInputText@11c55bb converter: com.sun.faces.taglib.jsf_core.ConverterTag$BindingConverter@1406eb6

        This test probe that JSF RI is doing a delegate pattern, and if a solution does this for myfaces, it remains compatible with JSF RI,
        which its my main objective.

        Show
        Leonardo Uribe added a comment - I have made a probe of my assumptions. If all previous discussion is true, what should return JSF RI UIOutput.getConverter() for any component that has a converter? If I use BigIntegerConverter, should return an object of the same type? I made a simple modification of the previous code. At each phase, print what is inside this property. As I hoped, it returns this This is the message for phase before APPLY_REQUEST_VALUES 2 Component:javax.faces.component.html.HtmlInputText@11c55bb converter: com.sun.faces.taglib.jsf_core.ConverterTag$BindingConverter@1406eb6 This test probe that JSF RI is doing a delegate pattern, and if a solution does this for myfaces, it remains compatible with JSF RI, which its my main objective.
        Hide
        Mike Kienenberger added a comment -

        There's a much better chance of getting discussion on this issue if you post a message to the dev mailing list rather than adding comments to the issue. If it's broad enough to include the JSF RI, you probably should cross-post between the jsf ri dev mailng list and the myfaces dev mailing list.

        Show
        Mike Kienenberger added a comment - There's a much better chance of getting discussion on this issue if you post a message to the dev mailing list rather than adding comments to the issue. If it's broad enough to include the JSF RI, you probably should cross-post between the jsf ri dev mailng list and the myfaces dev mailing list.
        Hide
        Martin Marinschek added a comment -

        As soon as you have a patch ready (with documentation), I'll take a look at it. I haven't looked to deep into the spec with regards to this binding attribute on converters/validators so far.

        regards,

        Martin

        Show
        Martin Marinschek added a comment - As soon as you have a patch ready (with documentation), I'll take a look at it. I haven't looked to deep into the spec with regards to this binding attribute on converters/validators so far. regards, Martin
        Hide
        Leonardo Uribe added a comment -

        After asking some questions on jsf ri dev mailing list, I finally understand the reasons
        about why create a delegator for actionListener, converter, validator and valueChangeListener.

        The actual behaviour in simple words is this.

        when you have a code like this:

        <f:actionListener binding="#

        {mybean}"/>
        <f:converter binding="#{mybean}

        "/>
        <f:validator binding="#

        {mybean}"/>
        <f:valueChangeListener binding="#{mybean}

        "/>

        or

        <f:actionListener type="#

        {'anyid'}" binding="#{mybean}"/>
        <f:converter converterId="#{'anyid'}

        " binding="#

        {mybean}"/>
        <f:validator validatorId="#{'anyid'}" binding="#{mybean}

        "/>
        <f:valueChangeListener type="#

        {'anyid'}

        " binding="#

        {mybean}

        "/>

        jsf ri 1.2_05 create a class that acts like a delegator to avoid create an
        instance of mybean instead of get the reference of the bean (through a lazy loading).

        If you have a component that define the type, converterId or validatorId as a simple
        String without EL, the behaviour is like the spec says (what myfaces does right now).

        The value of binding variable is irrelevant at each phase. It's just a way to custom
        create of components, so it's not necessary to define it previous INVOKE_APPLICATION phase.

        With this information, I have created a solution that is equivalent to jsf ri behaviour.

        In the patch there are this modifications:

        1. Create proper classes that acts as delegate pattern, and implements StateHolder called:

        org.apache.myfaces.taglib.core.DelegateActionListener
        org.apache.myfaces.taglib.core.DelegateConverter
        org.apache.myfaces.taglib.core.DelegateValidator
        org.apache.myfaces.taglib.core.DelegateValueChangeListener

        2. Create two classes called

        org.apache.myfaces.taglib.core.ConvertImplTag
        org.apache.myfaces.taglib.core.ValidatorImplTag

        There are other children classes from ConverterTag and ValidatorTag that does not
        implement this behaviour, so make a modification on it is wrong. It's better to create
        classes that implement this specific behaviour to this components.

        3. Modify GenericListenerTag, ActionListenerTag and ValueChangeListenerTag to implement
        this behaviour.

        The issue on javaserverfaces issue tracker (explaining the reason why they do the changes) is #471

        There whas a issue that change the behaviour form jsf ri 1.2_04-p02 to 1.2_05 is #631, to remain jsf ri
        compatible with trinidad converters:

        " ...... If 'converterId' attribute isn't an expression we should return the converter
        instead of the BindingConverter. ......"

        In a conversation with Ryan Lubke:

        ".... The change that was introduced was this:
        If id is specified and is a literal, then the converter will never
        change, so assign the actual
        converter instance instead of the binding instance. This was needed
        to support certain
        functionality provided by trinidad. ..."

        "... As it stands in the RI now, we're trying to accomodate what the spec
        says (i.e. literal id means actual instance instead of delegate)
        and improving upon the spec in how binding should have been spec'd out.

        Since the Trinidad component set relies on the current spec behavior, I
        think this hybrid solution is the best
        that we can do until JSF 2.0 clarifies this situation. ..."

        Show
        Leonardo Uribe added a comment - After asking some questions on jsf ri dev mailing list, I finally understand the reasons about why create a delegator for actionListener, converter, validator and valueChangeListener. The actual behaviour in simple words is this. when you have a code like this: <f:actionListener binding="# {mybean}"/> <f:converter binding="#{mybean} "/> <f:validator binding="# {mybean}"/> <f:valueChangeListener binding="#{mybean} "/> or <f:actionListener type="# {'anyid'}" binding="#{mybean}"/> <f:converter converterId="#{'anyid'} " binding="# {mybean}"/> <f:validator validatorId="#{'anyid'}" binding="#{mybean} "/> <f:valueChangeListener type="# {'anyid'} " binding="# {mybean} "/> jsf ri 1.2_05 create a class that acts like a delegator to avoid create an instance of mybean instead of get the reference of the bean (through a lazy loading). If you have a component that define the type, converterId or validatorId as a simple String without EL, the behaviour is like the spec says (what myfaces does right now). The value of binding variable is irrelevant at each phase. It's just a way to custom create of components, so it's not necessary to define it previous INVOKE_APPLICATION phase. With this information, I have created a solution that is equivalent to jsf ri behaviour. In the patch there are this modifications: 1. Create proper classes that acts as delegate pattern, and implements StateHolder called: org.apache.myfaces.taglib.core.DelegateActionListener org.apache.myfaces.taglib.core.DelegateConverter org.apache.myfaces.taglib.core.DelegateValidator org.apache.myfaces.taglib.core.DelegateValueChangeListener 2. Create two classes called org.apache.myfaces.taglib.core.ConvertImplTag org.apache.myfaces.taglib.core.ValidatorImplTag There are other children classes from ConverterTag and ValidatorTag that does not implement this behaviour, so make a modification on it is wrong. It's better to create classes that implement this specific behaviour to this components. 3. Modify GenericListenerTag, ActionListenerTag and ValueChangeListenerTag to implement this behaviour. The issue on javaserverfaces issue tracker (explaining the reason why they do the changes) is #471 There whas a issue that change the behaviour form jsf ri 1.2_04-p02 to 1.2_05 is #631, to remain jsf ri compatible with trinidad converters: " ...... If 'converterId' attribute isn't an expression we should return the converter instead of the BindingConverter. ......" In a conversation with Ryan Lubke: ".... The change that was introduced was this: If id is specified and is a literal, then the converter will never change, so assign the actual converter instance instead of the binding instance. This was needed to support certain functionality provided by trinidad. ..." "... As it stands in the RI now, we're trying to accomodate what the spec says (i.e. literal id means actual instance instead of delegate) and improving upon the spec in how binding should have been spec'd out. Since the Trinidad component set relies on the current spec behavior, I think this hybrid solution is the best that we can do until JSF 2.0 clarifies this situation. ..."
        Hide
        Leonardo Uribe added a comment -

        fixed at revision 600199

        Show
        Leonardo Uribe added a comment - fixed at revision 600199
        Hide
        Leonardo Uribe added a comment -

        There is a NPE when creating actionListeners like this:

        <f:actionListener
        type="#

        {calcForm.actionClass}

        "></f:actionListener>

        or

        <f:actionListener
        type="org.apache.myfaces.examples.example1.CalcActionListener"></f:actionListener>

        Show
        Leonardo Uribe added a comment - There is a NPE when creating actionListeners like this: <f:actionListener type="# {calcForm.actionClass} "></f:actionListener> or <f:actionListener type="org.apache.myfaces.examples.example1.CalcActionListener"></f:actionListener>
        Hide
        Leonardo Uribe added a comment -

        fixed at 600206

        Show
        Leonardo Uribe added a comment - fixed at 600206

          People

          • Assignee:
            Leonardo Uribe
            Reporter:
            Leonardo Uribe
          • Votes:
            0 Vote for this issue
            Watchers:
            0 Start watching this issue

            Dates

            • Created:
              Updated:
              Resolved:

              Development