Hi,
We recently upgraded to dwr version 3.0.2
We are seeing WARN logs when doing our regression testing.
Our method that it is referring to takes in a HashMap of which we retrieve String and Doubles… so I’m not 100% sure what we should add to the Signature section.
Any advice on this would be appreciated
Referenced Doc: http://directwebremoting.org/dwr/documentation/server/configuration/dwrxml/signatures.html
Log:
WARN - Missing type info for (method=<ourMethodNameHere>(class com.company.util.Hash, interface javax.servlet.http.HttpSession, interface javax.servlet.http.HttpServletRequest), parameter: 0). Assuming this is a map with String keys. Please add to <signatures> in dwr.xml (org.directwebremoting.util.LocalUtil)
Normally this should be handled automatically by DWR.
It would be helpful to know:
- Is this a new warning or was it there before the upgrade but not noticed / acted upon?
- Which DWR version are you upgrading from?
- Are you currently using DWR signatures in your project?
- What is the complete type signature of your
Hash class (extends/implements/template args) and the Hash parameter in your method?
Is a new warning - we recently upgraded from version: 2.0.4
Not 100% sure if the WARNS were there before this is something I can get someone to check
Not using signatures.
Snippet of the HASH we import into our front end application.
package com.company.util;
public class Hash extends HashMap
{
public Hash()
{
super();
}
public Hash(Hash source_hash)
{
super(source_hash);
}
public Hash(Object[] key_values)
{
for (int i=0; i<key_values.length; i+=2)
{
this.put(key_values[i],key_values[i+1]);
}
}
public void put(String key, int value)
{
this.put(key, new Integer(value));
}
public void put(String key, long value)
{
this.put(key, new Long(value));
}
Implementation in front end:
package com.company.services;
import com.company.util.Hash;
public class Services
{
public static Hash MethodNameHere(Hash params, HttpServletRequest request)
{
Hash p = new Hash();
p.put("Key", params.getString("Value"));
p.put("Key2", params.getString("value"));
/// ...
How we call the Services class:
var o = new Object();
o.value1 = getRawNumber($("#id1Here").val());
o.value2 = getRawNumber($("#id2Here").val());
o.amount = trim($("#total").html().replace("$", ""));
o.booleanValue = true;
Services.MethodNameHere(o, request);
Ok so it looks like your Hash class is not assigning the type parameters of the generic HashMap collection class.
This means you are effectively declaring a HashMap<Object, Object> collection which doesn’t translate well to standard JavaScript maps/objects. DWR’s warning is correct.
Though, it seems your Hash uses String for all key values? In that case the easiest and best solution is probably to update your Hash class so it assigns type parameters as HashMap<String, Object> and everything should keep working as before, minus the warning.
1 Like
Hi, yes all the keys are Strings but the value can vary.
We had thought we would have been able to add some sort of signature into dwr.xml, rather than fixing our back end code?
This class is contained in a microservice that is used by many projects in our organisation - so changing this service wouldn’t be ideal.
May I ask, in your opinion, would ignoring these logs be an issue? or should we do our best to fix it before deploying our application with this updated dwr?
Thanks
Ok, just so you know your current code has a bad smell and wouldn’t pass review if I was involved. I would urge your developers to learn correct use of generic collections.
Whether this kind of un-generic class can be fixed up with DWR signatures is unknown to me. You have already found the docs for signatures so try with something according to:
import com.company.services.Services;
import com.company.util.Hash;
import javax.servlet.http.HttpServletRequest;
Services.MethodNameHere(Hash<String, Object> params, HttpServletRequest request);
It is probably safe to say that no library or framework will try to solve problems that are caused by deliberately bending code outside recommended principles, so you will be on your own here.
With the current branch of DWR the behaviour will be the same (string keys) whether you fix the warning or not.
1 Like
Ok, yes I get where you’re coming from.
We will attempt a signature like the one you provided.
Although I do agree and do not like this workaround, I just know that changing the base Hash class will affect lots of other teams so it won’t be easy getting the go ahead to make the change.
Thanks for your help and your insight
Just a thought, from reading the documentation
Would adding a converter (<convert>) to the dwr.xml help in anyway?
Or are the basic converters that are already applied by default sufficient?
considering the problem lies with our current implementation of the HashMap
Our current dwr.xml:
<!DOCTYPE dwr PUBLIC
"-//GetAhead Limited//DTD Direct Web Remoting 3.0//EN"
"http://getahead.org/dwr/dwr30.dtd">
<dwr>
<allow>
<convert converter="exception" match="com.company.struts.services.CustmomException">
<param name='include' value='message,responseCode'/>
</convert>
<convert converter="bean" match="com.company.struts.beans.*"/>
<create creator="new" javascript="Services">
<param name="class" value="com.company.struts.services.Services"/>
<exclude method="processChargeBackAction"/>
</create>
<create creator="new" javascript="Format">
<param name="class" value="com.company.struts.util.Format"/>
</create>
<create creator="new" javascript="CompanyUtil">
<param name="class" value="com.company.struts.util.Util"/>
</create>
</allow>
</dwr>
Your HashMap-based classes are handled through an implicit converter configuration for all “maps” so it is not mentioned currently in your dwr.xml. You could make an explicit configuration but there are still no conversion properties you can set that would get rid of the warnings.
Though, you could write your own map converter according to your taste and then configure it through dwr.xml. But please don’t. You will be creating a bigger mess in your project than you already have. Just configure your logger to silence all warnings instead and move on.