> I think we'll probably do a 1.2_05 RC2 soon. This second
> RC will have the fix.
do you know a date for this ?
-Matthias
>
>
> > And what's actually the version-number.
> > (I have hard time to understand the version numbers :-D)
> >
> > Thanks Ryan!
> >
> > -Matthias
> >
> > On 9/5/07, Matthias Wessendorf <matzew_at_apache.org> wrote:
> >
> >> filed an issue:
> >>
> >> https://javaserverfaces.dev.java.net/issues/show_bug.cgi?id=631
> >>
> >> -Matthias
> >>
> >> On 9/5/07, Matthias Wessendorf <matzew_at_apache.org> wrote:
> >>
> >>> Hi,
> >>>
> >>> I noticed an issue, when using the <f:converter /> tag.
> >>> The issue I noticed is present with these two RI version:
> >>> -1.2_04-b10-p01
> >>> -1.2_04-p02
> >>>
> >>> Running my application with version "1.2_03", the issue isn't there.
> >>>
> >>> Background:
> >>> In Apache MyFaces Trinidad, we replace the standard NumberConverter,
> >>> by our own converter, for instance to have support for client side
> >>> conversion.
> >>>
> >>> The trinidad-impl...jar/META-INF/faces-config.xml does this:
> >>>
> >>> <converter>
> >>> <display-name>Number Converter</display-name>
> >>> <converter-id>javax.faces.Number</converter-id>
> >>> <converter-class>org.apache.myfaces.trinidadinternal.convert.NumberConverter</converter-class>
> >>> </converter>
> >>>
> >>> To make it clear, this NumberConverter extends the standard
> >>> NumberConverter. Here is the hierarchy:
> >>>
> >>> javax.faces.convert.NumberConverter
> >>> |_ org.apache.myfaces.trinidad.convert.NumberConverter
> >>> |_ org.apache.myfaces.trinidadinternal.convert.NumberConverter
> >>>
> >>>
> >>> So, the problem is, when doing this in a JSPX file
> >>>
> >>> <inputXyz ...>
> >>> <f:converter converterId="javax.faces.Number" />
> >>> </inputXyz>
> >>>
> >>> The converter is instanceof
> >>> "com.sun.faces.taglib.jsf_core.ConverterTag$BindingConverter"
> >>>
> >>> When doing this:
> >>> <inputXyz ...>
> >>> <tr:converterNumber />
> >>> </inputXyz>
> >>>
> >>> The converter is instanceof
> >>> "org.apache.myfaces.trinidadinternal.convert.NumberConverter"
> >>>
> >>> Since our "converter replacements" like:
> >>> -org.apache.myfaces.trinidadinternal.convert.IntegerConverter
> >>> -org.apache.myfaces.trinidadinternal.convert.LongConverter
> >>> -org.apache.myfaces.trinidadinternal.convert.NumberConverter
> >>> -...
> >>> (to name only three)
> >>>
> >>> are implementing "extra" interfaces, like
> >>> "org.apache.myfaces.trinidad.convert.ClientConverter"
> >>> we are doing checks like
> >>>
> >>> if (converter instanceof ClientConverter)
> >>> {
> >>> ...
> >>> }
> >>> else
> >>> {
> >>> ...
> >>> }
> >>>
> >>> therefore usage of "<f:converter converterId="javax.faces.Number" />"
> >>> causes some issues.
> >>> I expected that this converter would be our replaced converter, but
> >>> it's instanceof
> >>> "com.sun.faces.taglib.jsf_core.ConverterTag$BindingConverter". So a
> >>> check against the "extra" interfaces isn't possible, when using
> >>> <f:converter ... />
> >>>
> >>> Another issue that could come up with this, is that someone creates a
> >>> "custom converter", that implements the Trinidad API
> >>> ClientConverter-Interfaces as well, but the developer is to lazy to
> >>> provide a tag... The only usage would be <f:converter /> but, this
> >>> custom converter will never be handled as a client-converter.
> >>>
> >>> Thanks,
> >>> Matthias
> >>>
> >>> --
> >>> Matthias Wessendorf
> >>>
> >>> further stuff:
> >>> blog: http://matthiaswessendorf.wordpress.com/
> >>> mail: matzew-at-apache-dot-org
> >>>
> >>>
> >> --
> >> Matthias Wessendorf
> >>
> >> further stuff:
> >> blog: http://matthiaswessendorf.wordpress.com/
> >> mail: matzew-at-apache-dot-org
> >>
> >>
> >
> >
> >
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: dev-unsubscribe_at_javaserverfaces.dev.java.net
> For additional commands, e-mail: dev-help_at_javaserverfaces.dev.java.net
>
>
--
Matthias Wessendorf
further stuff:
blog: http://matthiaswessendorf.wordpress.com/
mail: matzew-at-apache-dot-org