Hello,
In short, seems for now you have to work this around as you said...
later you can start using a fixed FM though where this won't be
necessary. And thanks for noticing this!
Said longer... I'm certain I can figure out a fix for this in 2.3.21,
however that's far away from being released. Although the fix of this
will be probably in the trunk soon, and the current state of trunk
should be stable. For the fix to be activated in 2.3.21 or in the
trunk, the "object_wrapper" setting value has to be a BeansWrapper
(like a DefaultObjectWrapper) that was created/getInstance-d with
Version(2, 3, 21) argument, or else the legacy behavior will be
emulated for backward compatibility. Or if you leave "object_wrapper"
at its default value, setting the "incompatible_improvement" setting
of the Configuration object has similar effect, although that actives
some other not-100%-backward-compatible fixes too. Note that
overloaded method selection was heavily reworked in 2.3.21, so there
are other changes too. (Why even that fails in this seemingly simple
case? The common type of the parameters on the 2nd position is
java.io.Serializable. So then FM concludes that whatever value it
comes up with for that position, it must be Serializable. That would
be fine, if it was a true requirement, but Java has this quirk that
Object[] is Serializible, despite you can't know if its items will be
Serializable, while java.util.List (the "default" Java-type of the FTL
sequence type) is rightfully not Serializable. That's ultimately why
FM thinks the conversion won't work out and it doesn't "unwrap" the
sequence.)
--
Thanks,
Daniel Dekany
(Sorry about the double post; I accidentaly hit ctrl+enter before I was finished)
We have a need for calling a method on the Spring
public String getMessage(String code, Object[] args)
${messageAccessor2.getMessage("my.parmeterizedMessage", [ "paramfromtemplate2", "PFT1" ] )}
No compatible overloaded variation was found for the signature
method getMessage(string (wrapper: f.t.SimpleScalar), sequence (wrapper: f.t.SimpleSequence))
org.springframework.context.support.MessageSourceAccessor.getMessage(org.springframework.context.MessageSourceResolvable, Locale),
org.springframework.context.support.MessageSourceAccessor.getMessage(String, Object[]),
org.springframework.context.support.MessageSourceAccessor.getMessage(String, Object[], String, Locale),
org.springframework.context.support.MessageSourceAccessor.getMessage(String, String),
org.springframework.context.support.MessageSourceAccessor.getMessage(org.springframework.context.MessageSourceResolvable),
org.springframework.context.support.MessageSourceAccessor.getMessage(String),
org.springframework.context.support.MessageSourceAccessor.getMessage(String, Object[], String),
org.springframework.context.support.MessageSourceAccessor.getMessage(String, String, Locale),
org.springframework.context.support.MessageSourceAccessor.getMessage(String, Object[], Locale),
org.springframework.context.support.MessageSourceAccessor.getMessage(String, Locale)
Is there a way, or do we need to create a wrapper object?
Eirik
There is no high like a tango high
There is no low like a tango low