You are viewing a plain text version of this content. The canonical link for it is here.
Posted to dev@myfaces.apache.org by "Leonardo Uribe (JIRA)" <de...@myfaces.apache.org> on 2008/11/20 23:14:44 UTC

[jira] Commented: (TOMAHAWK-1373) Tomahawk overrides converters back to their defaults

    [ https://issues.apache.org/jira/browse/TOMAHAWK-1373?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=12649500#action_12649500 ] 

Leonardo Uribe commented on TOMAHAWK-1373:
------------------------------------------

This problem comes from jsf 1.1. Converters for BigInteger and BigDecimal classes are not on faces-config.xml, but this was solved on jsf 1.2. 

On tomahawk 1.2 faces-config.xml, we can remove the fix for BigInteger and BigDecimal (I'll commit this change), but the converter for class java.util.Date not, because it is not present on both 1.1 and 1.2 and we should preserve backwards compatibility.

There are alternatives like set the converter for java.util.Date on webapp faces-config.xml, and others.

If no objections I'll close this issue as won't fix.

> Tomahawk overrides converters back to their defaults
> ----------------------------------------------------
>
>                 Key: TOMAHAWK-1373
>                 URL: https://issues.apache.org/jira/browse/TOMAHAWK-1373
>             Project: MyFaces Tomahawk
>          Issue Type: Bug
>    Affects Versions: 1.1.7
>            Reporter: Vadim Dmitriev
>            Priority: Minor
>
> In our project we use myfaces, trinidad, tomahawk, richfaces (extreme mix, but it does work... sometimes)
> Until the other day everything was alright, but one of our clients reported "all dates are displayed with -1 day offset". And that time I thought: yes, this is just because their appserver is configured in different timezone form their DB. But no, TZ was the same. Then I remembered that JSF spec defaults TZ to GSM+0 and that trinidad had it's own datetime converter that uses appserver's TZ by default. And we even fixed all problems on IBM websphere just by using trinidad's converter. Until other client complained about the same on Oracle AS. While debugging the issue I found that trinidad doesn't override default converter for java.util.Date on Oracle, but does on Websphere!
> The difference is simple: oracle's JVM enumerates JARs in a directory in different order from IBM's. So on Oracle AS trinidad was overriding Date converter, but it was overriden back to default by tomahawk. On websphere trinidad was loaded the last, so it's overrides were final.
> I was just wondering: why there was the need to override converters to their defaults in the first place? Maybe these overrides should be removed from tomahawk's faces-config.xml to not interfere with other libraries configs?

-- 
This message is automatically generated by JIRA.
-
You can reply to this email to add a comment to the issue online.