* Re: tests with rmic
@ 2005-10-19 8:10 Nicolas Geoffray
0 siblings, 0 replies; 4+ messages in thread
From: Nicolas Geoffray @ 2005-10-19 8:10 UTC (permalink / raw)
To: mauve-discuss
Hi Audrius
Meskauskas Audrius wrote:
>
> I looked at our gnu.java.rmi.server.UnicastRef and - yes,
> unfortunately it seems that there is system property in Classpath that
> would force the object serialization even if the RMI client and server
> are in the same machine.
>
> If you plan serious testing work, we should probably add such property
> as a necessary testing tool, but altering RMI implementation requires
> to have a test suite first. I think, you can commit such tests anyway
> because the object serialization is not the only thing in RMI that
> deserves testing.
>
Unfortunately I do not plan for the moment serious rmi testing work. I
just wanted to report a bug within gnu classpath. Because the test
involves launching at least 2 vms, it's difficult to reveal the bug. The
property forcing serialization would be great in my case!
Cheers,
Nicolas
^ permalink raw reply [flat|nested] 4+ messages in thread
* Re: tests with rmic
2005-10-18 11:47 ` Nicolas Geoffray
@ 2005-10-18 18:10 ` Meskauskas Audrius
0 siblings, 0 replies; 4+ messages in thread
From: Meskauskas Audrius @ 2005-10-18 18:10 UTC (permalink / raw)
To: mauve-discuss
>I can't use threads in a same virtual machine, because there is no
serialization of objects in RMI when the server and the client lives in
the same virtual machine (maybe it's possible enabling a flag somewhere,
but i don't know the API)
I looked at our gnu.java.rmi.server.UnicastRef and - yes, unfortunately
it seems that there is system property in Classpath that would force the
object serialization even if the RMI client and server are in the same
machine.
If you plan serious testing work, we should probably add such property
as a necessary testing tool, but altering RMI implementation requires to
have a test suite first. I think, you can commit such tests anyway
because the object serialization is not the only thing in RMI that
deserves testing.
Audrius.
^ permalink raw reply [flat|nested] 4+ messages in thread
* Re: tests with rmic
2005-10-17 17:13 Nicolas Geoffray
@ 2005-10-18 2:37 ` Chris Abbey
2005-10-18 8:41 ` tests with rmic! Meskauskas Audrius
1 sibling, 0 replies; 4+ messages in thread
From: Chris Abbey @ 2005-10-18 2:37 UTC (permalink / raw)
To: mauve-discuss
On Monday 17 October 2005 12:13, Nicolas Geoffray wrote:
> rmiregistry &
> jamvm ReceiveObjectImpl &
> jamvm Main
>
> Any suggestions?
Mauve style guidelines aside (because I have no idea what they would encourage
here), I'd encourage you not to start the default rmiregistry in any test
framework, as it creates a dependency on the runtime environment.
(Specifically that whoever is running the testcase doesn't already have an
rmi registry up.) Instead, I'd suggest that the ReceiveObjectImpl class binds
your own registry to an off the wall port that you've selected, and then in
the test case, you locate on that same port. This does create the problem
that you'll have to pick a port that's not in use, one solution to that is to
use a fallback pattern to select the port and write it to a file that the
test case loads to find out where the registry is. Also, by creating the
registry in the test server, you ensure that it goes away when the test is
done. The test server should also have a dead man's switch to exit after a
finite amount of time, otherwise you have to try to ensure some cleanup
externally, and most of the ways I've seen of doing that have some *bad* side
effects. (case in point at work, we have a few very large shared development
machines, occasionally, folks would get failures in some of the test buckets
they were running that just didn't make sense... further digging found a test
case like this that wanted to clean up after itself, so it did a ps list and
killed any task with it's name in it. This works fine as long as there is
only one instance of the test suite running. Another routinely killed the
snmpd on the system, because the test case fired up it's own with a unique
config, on the default port, and then when the test failed because it was
running iwht the wrong snmpd config, it blasted all instances of snmpd on the
box.) Anyway, client/server test cases usually need some extra thought put
into them was my only point before I started rambling.
/me re-lurks now.
--
Never make a technical decision based upon the politics of the situation.
Never make a political decision based upon technical issues.
The only place these realms meet is in the mind of the unenlightened.
-- Geoffrey James, The Zen of Programming
^ permalink raw reply [flat|nested] 4+ messages in thread
* tests with rmic
@ 2005-10-17 17:13 Nicolas Geoffray
2005-10-18 2:37 ` Chris Abbey
2005-10-18 8:41 ` tests with rmic! Meskauskas Audrius
0 siblings, 2 replies; 4+ messages in thread
From: Nicolas Geoffray @ 2005-10-17 17:13 UTC (permalink / raw)
To: mauve-discuss
[-- Attachment #1: Type: text/plain, Size: 536 bytes --]
Hi everyone,
I found what might be a bug in gnu classpath and I would like to commit
a testlet in mauve. The thing is, my test involves compiling with rmic
and launching two gnu classpath jvms. I never commited in mauve, but
seeing other testlets, i didn't found ways to commit such a test.
I attached the files. This is how you launch the test:
gcj -C Main.java
gcj -C ReceiveObject.java
gcj -C ReceiveObjectImpl.java
rmic ReceiveObjectImpl
rmiregistry &
jamvm ReceiveObjectImpl &
jamvm Main
Any suggestions?
Thanks,
Nicolas
[-- Attachment #2: Main.java --]
[-- Type: text/x-java, Size: 443 bytes --]
import java.rmi.Naming;
public class Main{
class Foo implements java.io.Serializable{}
class Bar implements java.io.Serializable{
Foo f = new Foo();
}
public static void main(String[]args){
try{
Bar b = new Bar();
ReceiveObject ref = (ReceiveObject) Naming.lookup("rmi://localhost/ReceiveObject");
ref.receiveObject(b);
}catch(Exception e){
System.out.println("Error : " + e );
}
}
}
[-- Attachment #3: ReceiveObject.java --]
[-- Type: text/x-java, Size: 179 bytes --]
import java.rmi.Remote;
import java.rmi.RemoteException;
public interface ReceiveObject extends Remote{
public Object receiveObject(Object unknown)
throws RemoteException;
}
[-- Attachment #4: ReceiveObjectImpl.java --]
[-- Type: text/x-java, Size: 535 bytes --]
import java.rmi.*;
import java.rmi.server.*;
public class ReceiveObjectImpl extends UnicastRemoteObject implements ReceiveObject{
public ReceiveObjectImpl() throws RemoteException{
}
public Object receiveObject(Object unknown)
throws RemoteException{
System.out.println(unknown);
return null;
}
public static void main(String[] args){
try{
ReceiveObject ref = new ReceiveObjectImpl();
Naming.rebind("ReceiveObject", ref);
}catch(Exception e){
e.printStackTrace();
}
}
}
^ permalink raw reply [flat|nested] 4+ messages in thread
end of thread, other threads:[~2005-10-19 8:10 UTC | newest]
Thread overview: 4+ messages (download: mbox.gz / follow: Atom feed)
-- links below jump to the message on this page --
2005-10-19 8:10 tests with rmic Nicolas Geoffray
-- strict thread matches above, loose matches on Subject: below --
2005-10-17 17:13 Nicolas Geoffray
2005-10-18 2:37 ` Chris Abbey
2005-10-18 8:41 ` tests with rmic! Meskauskas Audrius
2005-10-18 11:47 ` Nicolas Geoffray
2005-10-18 18:10 ` tests with rmic Meskauskas Audrius
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for read-only IMAP folder(s) and NNTP newsgroup(s).