smartgwt attribute problem

John Mazzitelli mazz at redhat.com
Sat Feb 5 07:21:47 UTC 2011


it appears this was most probably a side effect of the smartgwt upgrade. 
I ended up wrapping my map in a non-collection pojo and it started 
working again. I think smartgwt 2.4 is more strict in the types of maps 
it can store as an attribute.

On 02/05/2011 01:38 AM, John Mazzitelli wrote:
> This *used* to work. Now it doesn't.  Does any of this ring a bell as to
> why this would happen? My first thought was this changed between
> smartgwt 2.2 to 2.4 (since I haven't looked at this since the 2.4
> upgrade). I can't think of anything that would have changed in here
> since it was working.
>
> I have a form item that I set an attribute on (see
> ResourceOperationNotificationSenderForm, line 449):
>
>      operationSelectItem.setAttribute(OPERATION_DEFS_ATTRIBUTE, (Object)
> opDefs);
>
> opDefs is really of type:
>
>      LinkedHashMap<Integer, OperationDefinition>
>
> Stepping through, it looks like smartgwt is trying to do some internal
> conversion of that map... and it now assumes the keys are all Strings:
>
> com.smartgwt.client.util.JSOHelper.convertMapToJavascriptObject(Map)
>
>      for (Iterator iterator = valueMap.keySet().iterator();
> iterator.hasNext();) {
>         String key = (String) iterator.next();
>
> Even if I make the keys strings, reading the code further in this
> smartgwt class, I don't think it is gonna like OperationDefinition as
> the values.
>
> I think this is what is causing the problem. Anyone know if this is
> different in smartgwt 2.4 vs. 2.2?
>
> _______________________________________________
> rhq-devel mailing list
> rhq-devel at lists.fedorahosted.org
> https://fedorahosted.org/mailman/listinfo/rhq-devel


More information about the rhq-devel mailing list