Bruce Snyder wrote:

> 
> This one time, at band camp, DU SONG Romuald said:
> 
> DSR>I have a look to your code in CVS to handle the bug, and I was
> DSR>wondering whether it would work because when you do :
> DSR>
> DSR> new TypeConvertorInfo( new SQLTypeConvertor( 
> java.lang.Integer.class,
> DSR>java.util.Date.class ) {
> DSR>            public Object convert( Object obj, String param ) {
> DSR>                try {
> DSR>                    getParamDateFormat().applyPattern(
> DSR>org.exolab.castor.mapping.loader.Types.getFullDatePattern(
>  param ) );
> DSR>                    return getParamDateFormat().parse( 
> obj.toString() );
> DSR>                } catch ( ParseException except ) {
> DSR>                    throw new IllegalArgumentException( 
> except.toString() );
> DSR>                }
> DSR>            }
> DSR>        } ),
> DSR>
> DSR>You apply a pattern on a clone, then you format with 
> another clone,
> DSR> is my understanding correct ?
> 
> Yes, currently that is how the code is written. You bring up a very
> good point because the real member variable does not actually have the
> pattern applied to it. Just thinking off the top of my head, I could
> wrap the whole thing in the setter. But I'm not sure if this is good
> enough unless I introduce some synchronization. I dont' think that I
> can just use a synchronization block in the getters and setters only,
> each block where the getters and setters are used will need to be
> synchronized. Below is an example including both of these ideas:
> 
>  new TypeConvertorInfo( new SQLTypeConvertor( java.lang.Integer.class,
> java.util.Date.class ) {
>             public Object convert( Object obj, String param ) {
>                 try {
>                     synchronized 
>                     {
>                     setParamDateFormat( 
> getParamDateFormat().applyPattern(
> org.exolab.castor.mapping.loader.Types.getFullDatePattern( 
> param ) ) );
>                     return setParamDateFormat( 
> getParamDateFormat().parse( obj.toString() ) );
>                     }
>                 } catch ( ParseException except ) {
>                     throw new IllegalArgumentException( 
> except.toString() );
>                 }
>             }
>         } ),
> 
> What do you think, Du Song? 
> 

You're not holding the cloned SimpleDateFormat, but you are rebuilding
a clone of the clone. Is it necessary to keep last format used ?

It might be safer and quicker to do something like this :
    public Object convert( Object obj, String param ) {
           try {
                        SimpleDateFormat fmt =
getParamDateFormat().applyPattern(
 org.exolab.castor.mapping.loader.Types.getFullDatePattern(  param ) ); 
 
                     return fmt.parse( obj.toString() );
                 } catch ( ParseException except ) {
                     throw new IllegalArgumentException(  except.toString()
);
                 }
             }
         } ),

This way, we are cloning, but we don't need to synchronize.


Ce message et toutes les pi�ces jointes (ci-apr�s le "message") sont �tablis � 
l'intention exclusive de ses destinataires et sont confidentiels. Si vous recevez ce 
message par erreur, merci de le d�truire et d'en avertir imm�diatement l'exp�diteur. 
Toute utilisation de ce message non conforme � sa destination, modification, diffusion 
ou toute publication, totale ou partielle, est interdite, sauf autorisation 
expresse.FININFO (et ses filiales) d�cline(nt) toute responsabilit� au titre de ce 
message, dans l'hypoth�se ou il aurait �t� modifi�, alt�r�, falsifi� ou encore �dit� 
ou diffus� sans autorisation.
-----------------------------------------------------
This message and any attachments (the "message") is intended
solely for the addressees and is confidential. If you receive this 
message in error, please delete it and immediately notify the 
sender. Any use not in accord with its purpose, any dissemination 
or disclosure, either whole or partial, is prohibited except formal 
approval. Neither FININFO (nor any of its subsidiaries or affiliates) 
shall be liable for the message if modified, altered, falsified, edited 
or diffused without authorization. 

----------------------------------------------------------- 
If you wish to unsubscribe from this mailing, send mail to
[EMAIL PROTECTED] with a subject of:
        unsubscribe castor-dev

Reply via email to