On 24/03/2015 11:11, Mark Sheppard wrote:
Hi Alan,
thanks for the feedback.
WRT test location, I followed what is already in place i.e.
javax/rmi/ssl had an existing test
so as RMI-IIOP falls under javax/rmi/PortableRemoteObject, placing the
test in this grouping seemed reasonable.
It's no bother to place it elsewhere if you wish.
To date then the directories containing the CORBA and RMI-IIOP tests
have been in the jdk_other group. I think it would be best not to have
them split between two groups. Adding this to jdk_other should do it:
javax/rmi \
-javax/rmi/ssl
WRT 1050, this is a conundrum, and there doesn't seem to be a
reliable way of obtaining a port to absolutely avoid a clash.
This is the orbd's standard port.
There doesn't seem to be a reliable way of obtaining a port to
absolutely avoid a clash.
The test relies on the observation that ephemeral ports on most
contemporary platforms are being allocated
outside the well known and application allocated port ( > 32K ).
It could use 1060 instead.
It possible that multiple concurrent orbd may be running, but I've
run the regression suite many times for this issue, and
multiple orbd execution hasn't shown up, yet.
You might need to look at the exclusiveAccess.dirs property in TEST.ROOT
to avoid several tests trying to run orbd at the same time.
Stuart has been battling a bunch of issues in other areas with "address
already in use" and may have some advice on how to approach this test. I
do see that orbd can run on other ports and also it might be possible to
start it via it's com.sun API rather than the launcher.
:
WRT stubs and ties, I was trying to avoid use of a shell script. A
once off generation of stub and tie was
a handy way to avoid this. I don't think jtreg has an @rmic or @idl
similar to @build or @compile?
This may be something to add to the testlibrary infrastructure.
-Alan.
