Hey Mark,
thanks for the review. Yes - that's a better way to obtain the
valueHandler - will make the change and push shortly.
regards,
Sean.
On 01/07/14 12:41, Mark Sheppard wrote:
Hi Sean,
fix looks good .. surprised to see that GF has been modified to use
HashMap and not the JDK wasn't!!
In anycase this should solve a few other interop issues
WRT the test, I wonder if it is more appropriate to use the
javax.rmi.CORBA.Util class to obtain the ValueHandler rather that
instantiating the impl classes (restricted) directly?
e.g.
import java.net.InetAddress;
import javax.rmi.CORBA.Util;
import javax.rmi.CORBA.ValueHandler;
public class HookPutFieldsTest {
public static void main(String[] args ) throws Exception {
CustomOutputStream os = new CustomOutputStream();
InetAddress a = InetAddress.getByAddress(null, new byte[]
{1,2,3,4});
ValueHandler vh = Util.createValueHandler();
vh.writeValue(os, a);
}
}
regards
Mark
On 27/06/2014 13:35, Seán Coffey wrote:
Looking for a review around this CORBA issue.
bug report : https://bugs.openjdk.java.net/browse/JDK-7095856
webrev : http://cr.openjdk.java.net/~coffeys/webrev.7095856/
Null values cause issue when processed by an IIOPOutputStream and I
can't see a reason why they wouldn't be allowed. Note that the
glassfish code already employs a HashMap to hold such values. I've
run CORBA SQE tests, unit tests and relevant TCK tests. No issues seen.
regards,
Sean.