Matthias Wessendorf wrote:
> Thanks for fixing it so fast!
>
> Here are my obligatorily questions...
>
> When is this available in a release?
>
It will be available in the final 1.2_05 release (which is in a
release candidate stage now).
I think we'll probably do a 1.2_05 RC2 soon. This second
RC will have the fix.
> 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
>>
>>
>
>
>